Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 03/19/2018 in Posts

  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
    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
  3. 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 4.2.1.2. Hope that helps, Philipp Disclaimer: I haven't checked all of your post for correctness and focused on the questions instead. .
  4. 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:
  5. 2 points
    Hello All, I ran static analysis on latest SystemC library [For Fun]. clang-tidy report looks fine (I gave a very fast look). clang++ --analyze produced followed warnings which I want to point out: warning: Path diagnostic report is not generated. Current output format does not support diagnostics that cross file boundaries. Refer to --analyzer-output for valid output formats In file included from ../src/sysc/datatypes/int/sc_int_base.cpp:66: ../src/sysc/datatypes/int/sc_int_base.h:574:22: warning: The result of the left shift is undefined because the left operand is negative m_val = ( m_val << m_ulen >> m_ulen ); ~~~~~~^~~~~~~~~ 1 warning generated. ../src/sysc/utils/sc_mempool.cpp:252:59: warning: Division by zero int which_allocator = cell_size_to_allocator[(sz - 1) / increment + 1]; ~~~~~~~~~^~~~~~~~~~~ 1 warning generated. warning: Path diagnostic report is not generated. Current output format does not support diagnostics that cross file boundaries. Refer to --analyzer-output for valid output formats warning: Path diagnostic report is not generated. Current output format does not support diagnostics that cross file boundaries. Refer to --analyzer-output for valid output formats warning: Path diagnostic report is not generated. Current output format does not support diagnostics that cross file boundaries. Refer to --analyzer-output for valid output formats ../src/sysc/utils/sc_string.cpp:181:19: warning: Use of memory after it is freed return strlen(rep->str); ^~~~~~~~ ../src/sysc/utils/sc_string.cpp:242:9: warning: Use of memory after it is freed if (--(rep->ref_count) == 0) ^~~~~~~~~~~~~~~~~~ ../src/sysc/utils/sc_string.cpp:357:9: warning: Use of memory after it is freed if (rep->ref_count > 1) { ^~~~~~~~~~~~~~ 3 warnings generated. warning: Path diagnostic report is not generated. Current output format does not support diagnostics that cross file boundaries. Refer to --analyzer-output for valid output formats In file included from ../src/sysc/kernel/sc_simcontext.cpp:32: In file included from ../src/sysc/kernel/sc_simcontext_int.h:37: ../src/sysc/kernel/sc_runnable_int.h:464:18: warning: Called C++ object pointer is null m_methods_pop = m_methods_push_head->next_runnable(); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Even if these will not pose a problem for running simulations, I will get my sanitizer and other tools irked out. Following is the script if anybody want to try. set x = `find ../src -name "*.cpp"` foreach item ($x) /home/sumit/local/clang/bin/clang-tidy \ -checks='*' \ `echo ${item}` \ -extra-arg=-std=c++17 -- -I ../src end /home/sumit/local/clang/bin/clang++ --analyze -std=c++17 -I ../src \ `echo $x` Please let me know, if there is further questions. Regards, Sumit
  6. 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
  7. 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
  8. 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.
  9. 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.
  10. 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
  11. 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.
  12. 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.
  13. 1 point
    Philipp A Hartmann

    Build error with 2.3.2

    The 'CMAKE_CXX_STANDARD' is specific to cmake. When you use automake/configure, you can configure the build by passing the '-std=c++11' flag directly to the configure call: ../configure ... 'CXXFLAGS=-std=c++11' Hope that helps, Philipp
  14. 1 point
    Actually this is not going to work as it is quite unlikely that both events fire at the same delta cycle. So you would write something like void do_dff(){ if(enable.read()) q=d; } sc_ctor(){ SC_METHOD(do_dff); sensitive << clk; } The only option to concatenate events is to use sc_core::sc_event_and_list and sc_core::sc_event_or_list but those can only use in dynamic sensitivity (wait() for SC_THREADs and next_trigger() for SC_METHODs). Best
  15. 1 point
    David Black

    reset method or thread

    Reset is accomplished by throwing an exception. You cannot perform cleanup *before*, but you can perform cleanup on the way out in two manners. First, automatically created objects will of course run their destructors as guaranteed by C++. Second, you can catch exceptions by strategic placement of try-catch blocks and looking for the appropriate sc_exception. It is required by SystemC that you rethrow after catching; otherwise, you will corrupt the SystemC kernel.
  16. 1 point
    Hi all, Both sc_get_current_process_b() and get_parent() are non-standard functions that may or may not be supported by (future) versions of your SystemC implementation. I recommend to only use standard IEEE 1666-2011 APIs instead: x sc_core::sc_get_current_process_handle().get_parent_object()->name() x sc_core::sc_get_current_process_handle().name() Greetings from Duisburg, Philipp
  17. 1 point
    sc_signal only triggers an event if you write a value different from the current one. If you want to trigger events and hence invoke method/sc_thread you need to use sc_buffer instead of sc_signal. It is a drop-in replacement. Best regards
  18. 1 point
    Yes, SystemC is doing exactly what is supposed to do. Perfect behavior and standard reaction when you don't understand event driven simulators. In Verilog/SystemVerilog, this behavior is called non-blocking assignment (NBA). In VHDL, this is the behavior of a signal.
  19. 1 point
    Hello @YashJ, It is expected behavior. Here is a brief explanation: //... // Find the inline comments: while(true){ wait(); //< Wait for default event sensitivty(static sensitive event!). In you case it is in.value_changed() cout<<"\nIN = "<<in.read()<<" TIME" <<sc_time_stamp()<<endl; inter.write(in.read()); //< Write to the inter signal -> which means schedule and event for updating the sc_signal. cout<<"\nInter before wait= "<<inter.read()<<endl; wait(10,SC_NS); //< Relinquish control to the SystemC scheduler -> perform evaluate and update phase for all event scheduled. (Change sensitivity to dynamic scheduled after 10 ns) out.write(inter.read()); //< inter has the new value assigned at 3 lines before this statement. cout<<"\nInter after wait= "<<inter.read()<<endl; cout<<"\nOUT = "<<out.read()<<" TIME" <<sc_time_stamp()<<endl; cout<<"\nIN when outed = "<<in.read()<<endl; } ///.... Hope it helps. Regards, Ameya Vikram Singh
  20. 1 point
    Eyck

    beginner problems on fifo waveform

    Hi, you cannot bind interface to e.g. a class implementing those interface. What you can bind are sc_port and sc_export. So you would need to change your declaration to sc_core::sc_port< sc_core::sc_fifo_out<int> > output1; sc_core::sc_port< sc_core::sc_fifo_in<int> > input1; But this is not going to solve your problem as you cannot trace an sc_core::sc_fifo_out interface. Tracing is only possible for elements having a value semantic which are variables of various types (primitive ones like int or composed ones coming with the SystemC library like sc_int or sc_bv) and signals (since they have also a value semantic). interfaces (like are sc_core::sc_fifo_in) are essentially description how to manipulate things and therefore not trace with a tracefile. Using SCV it would be possible to do so but requires implementing some glue code. BR
  21. 1 point
    Than you Joshua. I missed this update. Just applied the patch and it works fine. Appreciate the help.
  22. 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
  23. 1 point
    David Black

    Scope of SC_HAS_PROCESS

    Personally, I prefer to put SC_HAS_PROCESS directly into the constructor body, which works very reliably. All that SC_HAS_PROCESS does is to create a typedef called SC_CURRENT_USER_MODULE which refers to .... the current module name. It is only used in the three macros SC_THREAD, SC_METHOD and SC_CTHREAD. Syntactically, C++ allows a typedef to be created within a function (in this case the constructor function). Advantages of this approach: It's defined very close to the point of usage. The user of a header file, does not need to see it. /.h #import <systemc> // I never use systemc.h ... class Blah: sc_module { Blah(sc_module_name); ~Blah(); } //.cpp file #include "Blah.h" using namespace sc_core; Blah::Blah(sc_module_name nm): sc_module(nm) { SC_HAS_PROCESS(Blah); SC_THREAD(blah_thread); ... } Blah::~Blah(){ }
  24. 1 point
    svinco

    TLM payload extension declaration

    Dear all, I am new to payload extensions and I would appreciate a feedback on whether I am doing things right.. I need to declare a simple payload extension, including two additional fields: a reset value a 16 bit bit vector representing the value of a register In the header, I simply declare the clone/copy from functions, plus my additional fields: class reg_extension : public tlm::tlm_extension<reg_extension>{ public: reg_extension(); tlm::tlm_extension_base* clone() const ; void copy_from(tlm::tlm_extension_base const &); bool reset; sc_bv<16> value; }; And then I implemented the functions, by taking care of the additional reset and value fields: reg_extension::reg_extension(){ reset = false; value = sc_bv<16>(0); } tlm::tlm_extension_base * reg_extension::clone() const{ cout<<"Executing clone!"<<endl; reg_extension * ext = new reg_extension(); ext->reset = this->reset; ext->value = this->value; return ext; } void reg_extension::copy_from(tlm::tlm_extension_base const & ext){ reset = static_cast<reg_extension const &>(ext).reset; value = static_cast<reg_extension const &>(ext).value; } Is this enough for the extension to work? Best regards, S.
  25. 1 point
    There have been some improvements to the performance of the field automation macros, but I still do not believe their benefit is worth the cost. You should be able to prove it to yourself by creating a simple testbench with and without the macros.
×