Jump to content


Popular Content

Showing most liked content since 02/25/2017 in all areas

  1. 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
  2. 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.
  3. 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.
  4. 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]).
  5. 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
  6. 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.
  7. 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.
  8. 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
  9. 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
  10. 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
  11. 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
  12. 2 points
    Hello @Roman Popov, You can have a look here: Hope it helps. Regards, Ameya Vikram Singh
  13. 2 points
    Have you looked at the functions defined in clause 4.5.7 Functions to detect pending activity of IEEE Std. 1666-2011? Using the simcontext directly is not advisable as its interface is not part of the SystemC standard. It is thus an implementation detail of the Accellera proof-of-concept implementation of SystemC on which you should not depend on if you want a portable solution.
  14. 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
  15. 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
  16. 2 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
  17. 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
  18. 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:
  19. 2 points

    Socket binding to module itself

    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!
  20. 1 point
    This has nothing to do with SystemC, but more to do with your declaration. You are declaring an array of pointers to integers on the stack. Stack in SystemC is 64k by default, which means you are limited to 64k/sizeof(int*). I suspect you intended to declare a pointer to an array of ints: int (*matrix)[]; // Pointer to array of int or int** matrix; I suggest you read at least one of the following: https://www.codeproject.com/Articles/7042/How-to-interpret-complex-C-C-declarations https://www.geeksforgeeks.org/complicated-declarations-in-c/ https://medium.com/@bartobri/untangling-complex-c-declarations-9b6a0cf88c96 For simplicity, I like the following tool: https://cdecl.org
  21. 1 point
    David Black

    Getting a bit from bus

    First thing you need to realize is that sc_signal<> is not a wire and it is not a data type. sc_signal<> is a channel with a non-blocking write and a blocking read. You cannot "connect" a variable to a signal. You have to explicitly make the transfer each time the value changes. There is no equivalent to a Verilog continuous assignment. How do you know if a signal has changed? You have to explicitly watch/wait for the change using additional methods value_changed_event() or possibly posedge_event() if using sc_signal<bool> or sc_signal<sc_logic>. Due to overloading of operator=(), the innocuous looking busCON10 = var_bus_CON[10] turns into: busCON10.write(var_bus_CON[10].read()); which will not return a value until the end of the next delta cycle. Using a cout << busCON directly after this will yield the current delta's value.
  22. 1 point

    Explicit parent object

    In our code we sometimes create sockets on demand. I.e. when some other modules ask for a socket during elaboration of the design instead of in the constructor of the module to which the socket belongs. This works great in general, but the hierarchical name of the created sockets end up in the scope of the module asking for the socket rather than in the scope of the module that has the socket. So when creating the sockets I would need to be able to explicitly set the parent object of the socket, but I haven't yet found a way to do this. Is there a way, or is this something to add to upcoming revisions of the standard and POC simulator?
  23. 1 point

    thread resets and events

    Hello @fdoucet, What your are trying to do here in this specific scenario is known as dynamic sensitivity. Dynamic sensitivity replaces the default sensitivity of the registered SystemC process, once the event it triggered the default sensitivity would be restored for the corresponding process. Here is a reference to the discussion before in this forum: http://forums.accellera.org/topic/1210-static-and-dynamic-sensitivity/ Hope it helps Regards, Ameya Vikram Singh
  24. 1 point
    Without a minimal self-contained example exposing your problem, it is hard to give an answer to your question. Did you set besides the data pointer also the data length correctly in your instance of the TLM generic payload? By the way, in C++ and SystemC, you should not use malloc() and free() to allocate/deallocate raw memory, Instead, you should prefer to use an appropriate container or C++'s new/delete operators as a last resort.
  25. 1 point
    David Black

    SystemC for Hardware Design

    For synthesizable SystemC, there is a standard, but even so it is VERY vendor/software dependent. So the answers for using SystemC in a synthesizable context depend on which synthesis software you intend to use. Several companies often software for this (including, but no limited to, Cadence, Xilinx, Mentor (now Siemens)). In general, my experience is that most C/C++ is synthesizable subject to some simple restrictions (e.g. may not use the heap (i.e. new/delete/malloc/free), which also often means you will not be able to use very much of the STL, which is heavily dynamic. Polymorphism is restricted if not forbidden by most of the tools as well. That said, I have successfully synthesized huge designs fairly easily and with decent results.
  26. 1 point
    Philipp A Hartmann

    Using sc_uint_base directly?

    First of all, we need to distinguish between SystemC in general and its synthesizable subset. Whenever something is not explicitly covered by the current synthesizable subset, it's probably best to include the HLS vendors in the discussion. This almost certainly includes sc_signal<sc_uint_base>. Vendors may support this as signal type, if they can derive the width of the signal (statically) during elaboration. But in a fully generic fabric model, this might be difficult. IIRC, the main difference between SystemC and MyHDL or Chisel is that the latter basically create an explicit "netlist" in memory during elaboration. Basically, the synthesis rules/tool is already embedded in the language (kernel) itself, knowing how to generate the elaborated model to Verilog from memory. In SystemC, a synthesis tool is implemented more like a compiler, i.e. working at the language level directly. These are very different approaches with different benefits and limitations. When you refer to "runtime-defined bitwidths", you certainly mean "elaboration-defined", because the widths cannot change once the simulation has started. But sc_uint_base doesn't know about elaboration/simulation. In order to reduce the risk of width mismatches, you would need a custom channel as suggested by Torsten. But as you said, such custom channels are not supported well by HLS tools. Long story short: Having an "elaboration-sized" signal could definitely help for HLS use cases like yours. The simulation model could be implemented quite easily based on a signal specialization for sc_(u)int_base/sc_(u)nsigned. But as long as HLS tools doesn't support it, its usage would be fairly limited. Have you talked to HLS vendors about this already? Last, but not least, I think that C++17 constexpr, especially in combination with if constexpr and auto return type deduction, will provide most of the required features to write generic "hardware construction code" efficiently. Such models would then automatically be synthesizable by an C++17 capable HLS tool, as the code is evaluated during compile time already.
  27. 1 point
    Hi Matthias, I would say, this is just an inadvertent editorial change. The normative text still explicitly includes this transition. I'll forward your finding to the Accellera/IEEE WGs to get this fixed in a future revision of IEEE 1666. Thanks for reporting, Philipp
  28. 1 point
    David Black

    redefinition of enum

    I concur with the idea of becoming more proficient in C++. This is the number one best way to improve your SystemC skills. It also helps to get good formal training on SystemC. Suggestions: Define your enum's inside your class declarations (e.g. inside a module). Then you enumeration items become CLASS_NAME::ENUM_NAME Adopt C++11 and use enum classes. See http://en.cppreference.com/w/cpp/language/enum for more details. Do both! Any serious C++ programmer should be using C++11 or C++14 by now unless restricted by some antiquated toolset. These are now well supported by modern versions of GCC, CLANG (LLVM), Microsoft Visual Studio, Oracle, and IBM. This even includes most embedded compilers.
  29. 1 point


    You're using 'var' as a variable name, but this is an SV keyword. Try naming your variable something different: fork automatic int idx = i; // ! `uvm_do_on(eseq_inst[var], p_sequencer.master_sequencer[var]) join_none
  30. 1 point
    Have a look here: https://isocpp.org/get-started
  31. 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.
  32. 1 point
    I can also add a quote from the Verilog Standard IEEE 1364-2005, $timescale, describing the grammar rules for the timescale support in VCD: So even here, only powers of 10 are allowed.
  33. 1 point
    For all of the bitwise modifiedWrite functions (oneToClear, oneToSet, oneToToggle, zeroToClear, zeroToSet, zeroToToggle) the specified bit write value changes the target bit and the opposite bit write value leaves the target bit unchanged. This provides atomic write access to modify a single bit within a field within a single write transaction. For fields with normal write behavior the write replaces the target field value with the write value. This feature was inherited and expanded from Accellera SystemRDL 1.0 standard which at least has equations for the few bitwise write behaviors it supports. The IEEE 1800.2-2017 UVM standard inherited this feature from IP-XACT and has a slightly better description. We'll make sure that the next version of the standard specifies more completely the behavior of modifiedWrite.
  34. 1 point
    Hi Avihai, I can confirm this behavior with the latest SystemC 2.3.2 pre-release and would classify this as a bug. As a short-term workaround, you can mark affected threads with dont_initialize(), which happens not to trigger this misbehavior: SC_THREAD(thread1); sensitive << thread1_event; async_reset_signal_is(reset_in,true); dont_initialize(); // avoid crash when starting in reset state I'll forward this issue to the Language Working Group for further analysis. Greetings from Duisburg, Phiipp
  35. 1 point
    Here is an example of connecting serial port model to TCP socket: https://git.greensocs.com/models/tcp_serial
  36. 1 point

    systemC design

    Hello @yosri ben salah, As far as my experience is OpenCV image processing algorithms cannot be directly translated to synthesized design. It would involve manual translation of the algorithms in it's current form, but the work is progressing as mentioned here about utilizing the FPGA's. Regards, Ameya Vikram Singh
  37. 1 point
    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.
  38. 1 point
    Because clocked threads are sensitive to an explicit clock. This clock does not have to be active during the start of the simulation. Greetings from Duisburg, Philipp
  39. 1 point

    systemC on visual studio 2015

    Remove the include line stafx.h, as far as the differences are considered between Visual Studio and Linux certain header files will be different between them.
  40. 1 point
    Hi, the reason for the error is that you're not binding all your ports. You bind the ports in this loop: for(int i=0;i<n;i++) { for (int j=0;j<=i;j++) { std::cout << i << " " << j << " " << std::endl; test_CHOL0->chol_in_data[i][j](chol_in_data[i][j]); test_CHOL0->chol_out_data[i][j](chol_out_data[i][j]); } } but in the second loop you have j <= i. I've added printing and you can see that you only bind 6 of the 9 ports SystemC 2.3.1-Accellera --- Sep 3 2016 13:00:03 Copyright (c) 1996-2014 by all Contributors, ALL RIGHTS RESERVED 0 0 1 0 1 1 2 0 2 1 2 2 I think you need j < n regards Alan
  41. 1 point
    SystemC currently does not support to do several distinct simulations from within the same application process. Once elaboration is finished, you cannot instantiate new modules, ports, and channels, as they would modify the design hierarchy. Furthermore, after an sc_stop(), it is an error to call sc_start() again, see IEEE Std 1666-2011, clause 4.5.3: "It shall be an error for the application to call function sc_start after function sc_stop has been called." You may be able to arrange for your design hierarchy to stay constant across all simulation runs. In that case, you could make changes to the parameterization of the module instances in your hierarchy to modify stimuli and behavior each time an sc_start() hands back control to your sc_main(). If you need to do several simulations with divergent design hierarchies, you will have to launch an own process for each simulation case. You could store the parameters for the different simulation runs in one or more configuration files and pass this config file plus possible additional parameters as command line arguments to your SystemC application to easily switch between the different cases. A script file can then automate the execution of all the different necessary simulations.
  42. 1 point

    Doubt with TLM phase

    see the below image - ref OSCI TLM 2.0 LRM
  43. 1 point
    Tudor, Thanks for the reply. "properly it's necessary (but not sufficient) for the blocks to work properly." - What do you mean by "but not sufficient" ? I understand and agree. Revisiting this simple example I realized something so trivial it's almost embarrassing to admit ; I am still getting the top level functional checks using the block level environments. My concern was this: Using block level environments, each model gets its input from an agent, and not from a previous model output. In my mind, that implied the input might be incorrect; messed up possibly by the RTL block. However, I can guarantee the correctness to any stage because it was already checked in the previous stage. In short, I am an idiot.
  44. 1 point
    Hi Cliff, VCS provides a -top option for this, however it is a compile-time as far as I remember. Give it a try and see if that helps. Regards Srini www.verifworks.com
  45. 1 point

    Randomization in an initial block

    This is the correct functionality. There is a random number generator (RNG) for every module instance in your design, and it is seeded with a RNG from the module instance it starts from. All all modules instances start out with identical seeds. Every thread that starts inside a module instance grabs a new RNG. Threads in parallel blocks get seeded in declaration order, not in the indeterminate order they might actually start. Objects that get constructed get seeded with an RNG from the thread calling the constructor. This random stability model has a few problems that the UNM attempts to correct by using a path name as an initial seed. You just need to make sure your path names are unique enough to generate distinctive seeds. A good paper to read on this topic is: Random Stability, Don't leave it to chance.
  46. 1 point
    I believe 'force' is intended for net types (e.g. wire) and uses the SystemVerilog 'force' statement; whereas, 'deposit' is intended for variables (i.e. var or reg types). Lookup the 'force' and 'release' statements in the SystemVerilog standard for more information.
  47. 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
  48. 1 point

    loosely timed vs accurate timed ??

    Imagine you are modelling a bus-based system. You send a request to a slave on the bus. That request takes keeps the bus busy for 50 ns, and then the peripheral takes 25 ns to process the data. That means you can send a new request on the bus every 50 ns, before you have received the response from the slave. Req1 Req2 ---------|---------|--------- |---------|---------|--------- Resp1 Resp2 If you need to model at that level of detail, then you would use approximately timed modeling, with non-blocking transport. If you don't need that level of detail (perhaps you don't even know what bus you're using yet?) then loosely-timed might be appropriate (and faster) regards Alan
  49. 1 point
    Short answer: The standard requires an sc_trace overload for a user-defined (signal) datatype if and only if you actually trace this particular type. Defining the virtual function sc_object::trace would require an overload for each and every data type used within a primitive channel supporting traces, even if those signals are never traced. This would be quite inconvenient. /Philipp
  50. 1 point


    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