Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 08/23/2018 in all areas

  1. 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.
  2. 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
  3. 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.
  4. 2 points
    Hi, I'm not an implementer of the reference simulator but as far as I can judge the re-throw is used to find a more specific type of exception (since sc_elab_and_sim() just uses a catch-all) and uses sc_handle_exception() to convert it into an sc_report so it can be handled by the SystemC reproting system. Actually I agree it would be better to handle it directly in sc_elab_and_sim() but this would duplicate code. A side note rgd. debugging: if you use gdb there is a command 'catch throw' which stops execution right at the point where the (original) exception is thrown. This comes pretty handy in such cases. Best regards
  5. 1 point
    SystemC has no special concept similar to SystemVerilog interfaces. Instead you can use regular SystemC modules to work as SystemVerilog interfaces. SystemC has it's own notion of interface that is similar to interface notion in object-oriented programming: interface is basically a set of pure virtual functions. So for example you can define a simple memory interface as a set of mem_read and mem_write functions. SystemC requires that interfaces inherit virtually from sc_interface: struct memory_if : virtual sc_interface { virtual uint32_t mem_read( uint32_t address) = 0; // reads data from memory at given address virtual void mem_write( uint32_t address, uint32_t data) = 0; // writes data to memory at given address }; Next you can define a module that implements and exports this interface. For example: struct memory_module : sc_module, memory_if { sc_export<memory_if> mem_export{"mem_export"}; SC_CTOR(memory_module) { mem_export.bind(*this); } private: std::array<uint32_t , 1024> mem; uint32_t mem_read(uint32_t address) override { return mem.at(address >> 2); } void mem_write(uint32_t address, uint32_t data) override { mem.at(address >> 2) = data; } }; You can have other modules implementing memory_if. For example you can write a module that translates mem_read and mem_write function calls into a cycle-accurate signal-level memory protocol. And this is what SystemVerilog interfaces often do. Now the closest analog to SystemVerilog virtual interface is SystemC sc_port. For example you can define a test_module that has a sc_port<memory_if> and sends memory reads and writes using this port: struct test_module : sc_module { sc_port<memory_if> mem_port{"mem_port"}; SC_CTOR(test_module) { SC_THREAD(test_thread); } private: void test_thread() { cout << " test_thread \n"; const int TEST_SIZE = 10; for (int i = 0; i < TEST_SIZE; ++i) { cout << hex << "Write mem[" << i * 4 << "] = " << i << "\n"; mem_port->mem_write(i*4, i); } for (int i = 0; i < TEST_SIZE; ++i) { cout << hex << "Read mem[" << i * 4 << "] == " << mem_port->mem_read( i * 4 ) << "\n"; } } }; To create a simulation you instantiate both memory_module and test_module and bind port to export: int sc_main (int argc, char **argv) { test_module tmod{"tmod"}; memory_module mmod{"mmod"}; tmod.mem_port.bind(mmod.mem_export); sc_start(); return 0; }
  6. 1 point
    TRANG

    Initial value port

    Thank @David Black and @Roman Popov Thank you so much!!! But I think that, initialize the value depend on specification model require. Ex: Model A can reset Model B with reset port active with LOW level Then sc_out<bool> resetPort; in the Model A must be set initialize the value for resetPort is 1 on constructo´╗┐r So I think that , Should set initialize the value of port on constructo´╗┐r --> Clearly --> Easy maintain source code / //A.h class A: public sc_module { public: sc_in<bool> clkAPM; sc_out<bool> resetPort; sc_signal<bool> sig; ... ///A.cpp A::A(sc_module_name name) :sc_module(name) // Initializing ,clkAPM("clkAPM") ,resetPort("resetPort") ,sig("sig") {//{{{ /// Initializing resetPort.initialize(true); sig.write(true); SC_METHOD(AMethod); dont_initialize(); sensitive << sig ; ...
  7. 1 point
    You would need to write a wrapper class with debug aids builtin. A sketch might be: struct debug_mutex : sc_core::sc_mutex { void lock( void ) override { auto requester = sc_core::sc_get_current_process_handle(); INFO( DEBUG, "Attempting lock of mutex " << uint_ptr_t(this) << " from " << requester.name() " at " << sc_time_stamp() ); this->sc_mutex::lock(); locked = true; locker = requester.name(); time = sc_time_stamp(); changed.notify(); } void unlock( void ) override { auto requester = sc_core::sc_get_current_process_handle(); this->sc_mutex::unlock(); time = sc_time_stamp(); locked = false; locker = ""; changed.notify(); } // Attributes bool locked{ false }; sc_event changed; sc_time time; string locker; }; I have not tested above. NOTE: I have a macro INFO that issues an appropriate SC_REPORT_INFO_VERB with the above indicated syntax. Replace with your own. Never use std::cout or std::cerr if coding SystemC.
  8. 1 point
    AmeyaVS

    What is SystemC library special in?

    Hello @Elvis Shera, It seems your SystemC library has been build with different C++ standard flag. Can you post the output of following commands?: # Compiler version you are using g++ -v # Library Properties: nm -C $SYSTEMC_HOME/lib-linux64/libsystemc.so | grep api_version Regards, Ameya Vikram Singh
  9. 1 point
    Lukas Jakober

    Seeking Feedback on Datatypes

    Some feedback on AC datatypes: We have found AC datatypes to be an invaluable tool for large DSP ASIC designs. My experience is mostly on the simulation front where speed, bit- (but not necessarily cycle-) accuracy, and seamless integration with standard C++ code is important. AC datatypes provide all the relevant digital system design features (clipping/rounding/bit-slicing), as well as support for complex data types, with very little overhead. The ability to customize/expand AC datatype functionality via private headers (for simulation only) is another great benefit that minimizes the need for instrumentation code around HLS code during system simulations.
  10. 1 point
    maehne

    ELN Low pass filter

    Well, you will have to write a test bench, which provides your RC filter with some stimuli for transient simulation or sets up an AC analysis. However, I recommend you to have first a closer look to the fundamental concepts and ideas of SystemC AMS. A good introduction to SystemC AMS is provided by the SystemC AMS extensions User's Guide, which is part of the SystemC AMS extensions 1.0 release. Even though, this discusses only the features available sind SystemC AMS 1.0, it is a good start as SystemC AMS 2.0 and IEEE Std 1666.1 added mainly advanced features related to Dynamic TDF and bug fixes. Also, the SystemC AMS community pages provide some good links to introductory resources to get started with SystemC AMS.
  11. 1 point
    Roman Popov

    using gtkwave

    I don't work on Windows. But as far as I remember executable should be somewhere in project sub-directory called "Release" or "Debug". Sorry, can't help you more here.
  12. 1 point
    Roman Popov

    using gtkwave

    In the working directory (active directory when you launch the executable). Search for "and_gate.vcd"
  13. 1 point
    Eyck

    using gtkwave

    Actually SystemC provided sc_trace(...) functions where you register your signals and variables for tracing. Running the simulation yields a .vcd file which you can open in gtkwave. You may have a look into https://github.com/Minres/SystemC-Components-Test/blob/master/examples/transaction_recording/scv_tr_recording_example.cpp In sc_main() you will find sc_trace_file *tf = sc_create_vcd_trace_file("my_db"); sc_trace_file *tf = sc_create_vcd_trace_file("my_db"); This opens the waveform database. At the end you have to call sc_close_vcd_trace_file(tf); to properly close the database. 'tf' is a handle to the database, if you follow the code you will see how to trace signals (or variables), Best
  14. 1 point
    AmeyaVS

    Behavioral XOR Gate with Delay

    Hello @re1418ma, You can look at this example: http://forums.accellera.org/topic/5678-clock-to-q-propagation-delay/?do=findComment&comment=13657 Or this one which shows how to add delay in full adder: http://forums.accellera.org/topic/5715-delaying-simulated-execution/?do=findComment&comment=13844 Hope it helps. Regards, Ameya Vikram Singh
  15. 1 point
    In fact the fix is relatively simple, and will hopefully be in the next release (meantime, please find attached a small patch). The real question is why this inheritance structure was like this in the first place. Here's the PR rational: class tlm_put_get_imp <class1, class2> inherits private virtual from tlm_put_if<class1>, and tlm_get_peek_if<class2> tlm_put_if and tlm_get_peek_if are compounded class that are interfaces, which means that they (and their parents) have only pure virtual methods but these must be implemented because they are pure, so are they in tlm_put_get_imp, as publicmethods. So there is no point in the private inheritance. (Special thanks to Luc Michel from GreenSocs who helped sort this out) tlm1.patch
  16. 1 point
    Most likely you have C++98 in CMake cache. You don't need to modify SystemC CMakeLists, just set c++ standard from command line. Check here for detailed instructions https://stackoverflow.com/questions/46875731/setting-up-a-systemc-project-with-cmake-undefined-reference-to-sc-core
  17. 1 point
    Martin Barnasconi

    Error: System not scheduable

    It looks like you have a multi-rate system, i.e. somewhere you defined a <port>.set_rate(..) in a set_attributes callback. Now you try to access the n-th sample at this port, like <port>.read(<sample>), but the nth sample is higher than the rate specified. This means you have either the wrong rate, or reading a sample outside the range defined by the rate.
  18. 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(){ }
  19. 1 point
    David Black

    sytemc temperal decoupling

    Read IEEE 1666-2011 sections 9 & 10. Available for free download from http://www.accellera.org/downloads/ieee. Or watch a free video from https://www.doulos.com/knowhow/systemc/. Or take a class on SystemC & TLM from https://www.doulos.com/content/training/systemc_training.php. TLM 2.0 is a marketable skill and I get many requests for job references. You will need to become proficient at C++, SystemC fundamentals, and then TLM 2.0 in addition to having a good basic knowledge of hardware and software design.
  20. 1 point
    David Black

    approximately timed

    IEEE 1666-2011 section 10.2 states: IEEE 1666-2011 section 10.3.4 states:
  21. 1 point
    Hi Ameya, you're right: The SystemC 2.3.2 release selects a particular C++ standard to build upon and enforces consistency of this selection between the model and the library at link-time. Users can override the detection by setting the SC_CPLUSPLUS macro at build time to a (usually earlier) C++ version, as documented in the RELEASENOTES and INSTALL files of the SystemC 2.3.2 public review release. RELEASENOTES: 5) Initial support for C++11/14 =============================== This package includes an initial implementation of the C++11/14 proposal, presented at DVCon Europe 2016 ("Moving SystemC to a new C++ Standard"). This includes the addition of two new preprocessor symbols: - IEEE_1666_CPLUSPLUS (read-only) This symbol indicates the availability of certain SystemC features which depend on a particular version of the ISO C++ standard (see below). - SC_CPLUSPLUS (overridable) By default, the most recent supported version of the C++ standard for the current platform/compiler is automatically detected and reflected by the SC_CPLUSPLUS macro. Users can override (i.e. usually downgrade) the assumed C++ standard to an earlier version for compatiblity. The value of this macro has to be set consistently across the SystemC library build and all linked models (see INSTALL). The values of these macros follow the values defined by the C++ standards. Currently supported versions are: - 199711L (C++03, ISO/IEC 14882:1998, 14882:2003) - 201103L (C++11, ISO/IEC 14882:2011) - 201402L (C++14, ISO/IEC 14882:2014) The following features currently require a dedicated C++ standard version beyond ISO/IEC 14882:2003 (aka C++03): - C++11 (IEEE_1666_CPLUSPLUS==201103L) o explicit sc_bitref_r<>::operator bool() const Restricts direct boolean conversion of bitvector element references to explicit boolean contexts (e.g. `if` expressions). Use the `to_bool()` function on earlier setups. In the future, further language features depending on modern C++ language constructs may be added. INSTALL: * SC_CPLUSPLUS - Override automatically detected C++ standard support This setting allows downgrading the assumed version of the underlying C++ standard on the current platform. By default, the latest supported version is chosen. Supported values are * SC_CPLUSPLUS=199701L (C++03, ISO/IEC 14882:1998, 14882:2003) * SC_CPLUSPLUS=201103L (C++11, ISO/IEC 14882:2011) * SC_CPLUSPLUS=201402L (C++14, ISO/IEC 14882:2014) Note: This symbol needs to be consistently defined in the library and any application linking against the built library. Especially the last note in the RELEASENOTES is relevant to your question: In order to reduce the complexity of all the different C++ language support differences across compiler versions, the LWG decided to at least enforce a consistent selection of the C++ baseline in the proof-of-concept implementation. Of course, other vendors may chose to allow more flexibility here, although sometimes even a consistent compiler version selection is mandated. With this decision, the implementation does not have to worry about binary compatibility across different (C++ standard dependent) feature sets in the future. As of today, the (currently internal) classes sc_type_index, sc_string_view differ depending on the platform's C++ standard support. Future extensions might change other classes as well. Not worrying about the ABI compatibility is a helpful simplification here. As described above, you can set -DSC_CPLUSPLUS=... consistently on the compiler command-line to build a single library build across several GCC versions. If supported by your platform/compiler, you can still use the different -std=c++XY flags (or their defaults) from the compilers, provided that they generate compatible code across the selected C++ standard version. Hope that clarifies the rationale behind the current implementation. Greetings from Duisburg, Philipp
  22. 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...
  23. 1 point
    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!
  24. 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.
  25. 1 point
    apfitch

    loosely timed vs accurate timed ??

    In a loosely timed model you only have two timing points - start of transaction, end of transaction. In an approximately timed model using the base protocol, you have four timing points - start request, end request, start response, end response - hence you can model overlapped (pipelined) transactions, because you can start a new request before you have the response to the previous request. In my example above, you would only be able to send a new transaction every 75 ns using loosely timed, so the model of the timing of the transaction is less accurate - in the loosely timed model I can send a new transaction every 75 ns, in approximately timed every 50 ns using that example. If you do not use overlapped transactions, then you could just use begin request and end response, so as you say the non-blocking (approximately timed) and blocking (loosely timed) models would give the same results, regards Alan
×