Jump to content


Popular Content

Showing content with the highest reputation since 04/22/2018 in all areas

  1. 3 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<>m std::shared_ptr<>
  2. 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.
  3. 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.
  4. 1 point

    clock generation in system c

    The clock cycle is determined by the wait(1, SC_NS) statements withing the for loop. This defines the duration of the high and low phase of the clock you are seeing. The timesacel message comes from the VCD trace file (more specifically its writer) saying that the recording resolution will be teh default of 1ps which might be too small for some cases. You may ignore this message or explicitly set the VCD timescale. What Ameya is refering to is to replace the explicit clock generation with the SystemCs own sc_clock. This would alleviate you from describing the clock changes explicitly. Actually in my opinion this is a really bad example for several reasons: it bloats the sc_main function with testbench coder it mixes periodic signal change generation (the for loops) with functional code (writing reset and enable) it does not use SystemC utilities which make coding easier Best regards
  5. 1 point

    clock generation in system c

    Hello @veeresh k, This example does not have a dedicated clock generator. // These statements are what driving the clock signal to with High time of 1 ns and low time of 1 ns. for (i=0;i<10;i++) { clock = 0; sc_start(1, SC_NS);// Run simulation for 1 ns. clock = 1; sc_start(1, SC_NS);// Run simulation for 1 ns. } What message you receive from the SystemC kernel refers to the timescale of 1 ps e.g.: Info: (I702) default timescale unit used for tracing: 1 ps You can get the SystemC API documentation for the sc_clock from here: SystemC sc_clock api reference. If you need a sample you can find a use-case reference here(though a little bit-dated): https://github.com/AmeyaVS/SystemC_ramblings/blob/ff1a111063842bfcd6f5de6bb3db74917dc6331c/src/03_fir/firsytemmain.cpp#L26 Hope it helps. Regards, Ameya Vikram Singh
  6. 1 point

    system c beginner

    First, make sure that you are proficient in C++ as SystemC is a C++ library, which makes extensively use of advanced C++ features! Then, read a good introductory book on SystemC. I am personally not familiar with the SystemC Primer so cannot judge it. I found the book "SystemC from the Ground Up" by David C. Black, Jack Donovan et al. very helpful to learn SystemC.
  7. 1 point
    Some further comments: You don't need to keep handles to processes, if you don't intend to interact with them later. The crash you saw was likely caused by the fact, that the process was killed before you tried to register the sensitivity to it through your sc_event_and_list. Even if you kept the handle alive, you would still miss the notification: the process has already terminated when you run your wait(processes_complete); and the event will not be triggered again. It would be much safer to only store the handles and build up the event list locally to wait for the completion of still running processes: std::vector<sc_process_handle> processes; for(int i = 0; i < 10; ++i){ auto process = sc_core::sc_spawn(sc_bind(&My_Class::my_method, this, args)); processes.push_back(process); wait(10, SC_US); } // wait for running processes { sc_event_and_list processes_running; for( const auto& p : processes ) { if ( p.valid() && !p.terminated() ) processes_running &= p.terminated_event(); } wait( processes_running ); } For the second part (crash during process cleanup): Do you see a difference when spawning the thread during end_of_elaboration()? sc_spawn'ed threads from an start_of_simulation() callback a strictly speaking "dynamic threads" in the SystemC terminology, yes. But internally, they are still added to the process table in order to start them in the correct order relative to the rest of the kernel initialization. In the destructor however, only non-dynamic threads are removed from the process table. This means, you may have indeed found a bug in SystemC 2.3.2. I'll check this with the Language Working Group. Thanks and Greetings from Duisburg, Philipp
  8. 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
  9. 1 point
    Martin Barnasconi

    Tool support for SystemC-AMS

    My advice is to ask your EDA vendor for support. If they are not able to support you, then download the SystemC-AMS open source implementation yourself and compile it against a commercial SystemC-based simulator. After that create your (complex) design and show the simulation benefits to your EDA vendor, and explain (again) why SystemC-AMS is essential to have.
  10. 1 point

    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
  11. 1 point

    Changing the width in sc_bv<W>

    Hi Karthik, you need to provide a constant expression as template argument so that it can be evaluated at compilation time. See http://en.cppreference.com/w/cpp/language/constant_expression. and http://en.cppreference.com/w/cpp/language/template_parameters#Template_non-type_arguments. So it would need to be written as: const int WDW_SIZE = 2; Best regards -Eyck
  12. 1 point

    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.
  13. 1 point
    In general: Yes, this implementation is sufficient to implement a TLM2 extension. Still, there is a more reliable pattern to implement the copy_from and clone methods by using the copy constructor and assignment operator of your extension type (which you may need to implement in some cases anyway and will be provided for free in your particular example): class reg_extension : public tlm::tlm_extension<reg_extension> { public: tlm::tlm_extension_base* clone() const { return new reg_extension(*this); } // use copy constructor void copy_from(tlm::tlm_extension_base const & that ) { *this = static_cast<const reg_extension&>(that); } // use assignment operator // ... }; This pattern works very well for all Copyable and CopyAssignable classes without having to enumerate the members in clone and copy_from. Hope that helps, Philipp