Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 11/11/2015 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. 3 points
    AmeyaVS

    Clock to Q Propagation Delay

    Hello, In SystemC you can use SC_THREAD's to model delays by using wait statements but you will incur performance penalty. Instead you can use event's and event queues to model delays using in SystemC as mentioned here: http://workspace.accellera.org/Discussion_Forums/helpforum/archive/msg/msg?list_name=help_forum&monthdir=200803&msg=msg00061.html You can replace the SC_THREAD example given in the above mentioned link with SC_METHOD removing the infinite while loop. Here's the modified example listed from the above mentioned link: template<typename T> class delay_transport : public sc_module { public: sc_in<T> in; sc_out<T> out; SC_HAS_PROCESS(delay_transport); delay_transport(sc_module_name name_, sc_time tdelay_) : sc_module(name_), tdelay(tdelay_), in("in"), out("out") { SC_METHOD(mi); sensitive << in.default_event(); SC_METHOD(mo); sensitive << eq; } sc_time tdelay; void mi() { val = in.read(); vq.push(val); eq.notify(tdelay); } void mo() { val = vq.front(); out.write(val); vq.pop(); } sc_event_queue eq; std::queue<T> vq; T val; }; Regards, Ameya Vikram Singh
  3. 3 points
    An other way to understand this is to look at SystemC/TLM as pure C++ code and see what is going on.. Let us assume that you have two classes, "Initiator" and "Target", that need to communicate with each other. Target implements a function called "transport" to be called by Initiator, and Initiator implements a function called "response" - that is called by target. For the sake of the explanation here, the payload itself is not important, which we will assume is plain "int" in both directions. You would normally do this as following: // Interface classes: class initiator_if { public: void response(int i) = 0; }; class target_if { public: void transport(int i) = 0; }; class Initiator : public initiator_if { public: // Implement the interface void response(int i) { cout << "Got: " << i << " from target" << endl; } void bind(target_if &_if) { // Store the pointer locally m_target = &_if; } }; class Target : public target_if { public: // Implement the interface void transport(int i) { cout << "Got: " << i << " from initiator " << endl; } void bind(initiator_if &_if) { // Store the pointer locally m_initiator = &_if; } }; Next we instantiate the objects and "bind" them: Initiator initiator; Target target; initiator.bind(target); target.bind(initiator); I hope you are seeing where we are going with this. What has been done above is a crude equivalent of sc_port binding. There is one problem however with the approach above. What if the class "Target" doesn't implement the target_if directly? Like so: class TargetGrandChild : public target_if { public: void transport(int i) { // Implement the interface.. cout << "Got " << i << " from initiator (in grand child)" << std::endl; } }; class TargetChild { public: TargetGrandChild gch; /* Other stuff.. */ }; class Target { public: TargetChild ch; /* Other stuff.. */ }; One way to deal with this is to change the way bind function is called: initiator.bind(target.ch.gch); This is ugly. Firstly, it makes the client of bind function dependent on an internal design aspect of the "Target" class. For example, if the Target class changes tomorrow (to let the TargetChild implement the "target_if" directly), the bind function call needs to change. Also, to allow the client to call the bind function as above, the elements "ch" and "gch" must be made public, which may not be necessarily a good thing. A way out is to have an additional indirection. Let us call this as simple_export (a very simplified version of sc_export): class simple_export : public target_if { public: void transport(int i) { // One level of indirection p_real_target->transport(i); } void bind(target_if &_if) { p_real_target = &_if; } private: target_if *p_real_target; }; The new version of the Target class now looks like the following: class TargetGrandChild : public target_if { public: void transport(int i) { // Implement the interface.. cout << "Got " << i << " from initiator (in grand child)" << std::endl; } }; class TargetChild { public: TargetGrandChild gch; /* Other stuff.. */ }; class Target { public: simple_export port; private: // private is ok TargetChild ch; /* Other stuff.. */ Target() { // Tell "export" where the real implementation is port.bind(ch.gch); } }; The initiator will be "bound" to the target like so: initiator.bind(target.port); So for the simple_export to work, you need two binds: First is where the initiator is bound to the simple_export instance Second is when the "real" implementation is bound to the simple_export instance The simple_export class acts like a bridge. It forward the calls from the initiator to the "real" implementation. In case the "Target" itself implements the interface, the bind would look like: class Target : public target_if { public: simple_export port; private: // private is ok TargetChild ch; /* Other stuff.. */ Target() { // Tell "export" where the real implementation is port.bind(*this); } }; I hope this explains the line you pointed out in the code. The TLM socket has both a port and an export. Please note that the code snips above does not correspond to how OSCI simulator actually implements sc_port/sc_export!
  4. 3 points
    Admin

    Welcome!

    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
  5. 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.
  6. 2 points
    AmeyaVS

    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
  7. 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.
  8. 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.
  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
    ralph.goergen

    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
    You can use a custom "creator" to initialize elements of a vector with custom constructor parameters - here the inner vector. Something like this (assuming you have lambda support available): auto element_creator = [](const char* nm, size_t) // optional, depending on the "real" value type { return new sca_module(nm); }; size_t inner_size = 42; // adjust for your needs, could also be a vector of sizes element.init( outer_size, [&](const char* nm, size_t) { return new sc_vector<sca_module>( nm, inner_size, element_creator ); } ); If you don't have lambdas in your environment, you need to put the functionality in a custom function, e.g. static sc_vector<sca_module>* element_vector_creator(size_t size, const char* name, size_t) { return new sc_vector<sca_module(name, size); } // using sc_bind to pass in the size - placeholders needed for actual call element.init( outer_size, sc_bind(element_vector_creator, inner_size, sc_unnamed::_1, sc_unnamed::_2) ); Hope that helps, Philipp
  17. 2 points
    It's not sufficient that all the blocks work properly, because it might be the case that they aren't properly connected to each other. Outputs from some block are left hanging and the corresponding inputs are tied to some values. Cascaded block level checks can't really find this, if your observation points for each block level environment are its corresponding design block. Example: A can start read or write transactions, but the direction signal doesn't get passed to B, where it's tied to read. The A or B env checks won't fail, but the whole system is buggy.
  18. 2 points
    dave_59

    Help regarding fork_join usage

    You use fork/join_any statements when you want to create a number of time consuming processes and block waiting for one of them to finish. You create two processes, but they do not bloc - the finish immediately because they have fork/join_none statements in them . What you probably meant was something like initial begin me[0] = 1; me[1] = 2; me[2] = 3; repeat(5) begin : repeat_loop fork begin : b1 foreach(me) fork automatic int id = me; print_value (10+id,id); join_none wait fork; end : b1 begin :b2 foreach(me) fork automatic int id = me; print_value (20+id,id); join_none wait fork; end : b2 join_any disable fork; $display(" Disable Fork "); end :repeat_loop $display("@%g Came out of fork-join", $time); #20 $finish; end // initial begin
  19. 2 points
    Martin Barnasconi

    Error: System not scheduable

    I expect you have a loop (feedback path) in your design topology. This results in a circular dependency which cannot be resolved by the scheduler. To resolve this, add one time step delay, for example by specifying this delay in one of the output ports in the feedback path.
  20. 2 points
    This is my solution. Not necessarily the best one. Suggestions for improvements are welcome. If any of you find any shortcomings with this method, please let me know. Open to constructive criticism! /* Assume there are 3 requestors namely: A,B and C with reqA, reqB and reqC being the requests and gntA, gntB and gntC being the grants. Assumes the request and grant are on the same cycle Similar sequence and assertions need to be replicated for each requestor. Can concatenate the requests and grants into a bit vector, in order to save some redundant code */ //Denotes there is request and grant for the requestor A. Does not care about other requestors logic requestorA_req_and_gnt; //Denotes there is request and grant for requestor A and there is atleast one other requestor active logic requestorA_req_and_gnt_with_other_requestors_active; //There are requests other than requestor A logic other_req_except_requestorA; //There are grants other than requestor A logic other_gnt_except_requestorA; assign other_req_except_requestorA = reqB | reqC; //High when any one of the other requestor's are active assign other_gnt_except_requestorA = gntB | gntC; assign requestorA_req_and_gnt = reqA & gntA; assign requestorA_req_and_gnt_with_other_requestors_active = reqA && other_req_except_requestorA && gntA; //----------------------------------------------------------------------------------------------------------------------------------------------- // Covers the case where there is request and grant on one cycle for requestorA, followed by no other requests. And then few cycles later there // are multiple requests(reqA and atleast one other request). In this case, requestorA should NOT be granted again //----------------------------------------------------------------------------------------------------------------------------------------------- sequence requestorA_req_and_gnt_followed_by_other_req_seq; requestorA_req_and_gnt ##0 (!other_req_except_requestorA)[*1:$] ##1 reqA && other_req_except_requestorA; endsequence //----------------------------------------------------------------------------------------------------------------------------------------------- //Covers the case where there are more than one requestor active(reqA and any one of the other requests) followed by cycles of no other request at all // and again followed by more than one requestor active. First time during multiple requests, reqA is granted, so, the second time when multiple // requests are active, gntA should not be asserted again, and one of the other requests should be granted //----------------------------------------------------------------------------------------------------------------------------------------------- sequence multiple_requests_with_requestorA_req_and_gnt_followed_by_other_req_seq; requestorA_req_and_gnt_with_other_requestors_active ##1 (!other_req_except_requestorA)[*0:$] ##1 reqA && other_req_except_requestorA; endsequence //----------------------------------------------------------------------------------------------------------------------------------------------- //Covers the case where there are multiple requestors active in one cycle and next cycle may or may not have reqA, but will have other requests. // If reqA is granted in the previous cycle, it should not be granted again in the next cycle, rather other requestor should be granted //----------------------------------------------------------------------------------------------------------------------------------------------- sequence back_to_back_multiple_requests_active_with_requestorA_gnted_followed_by_other_req_seq; requestorA_req_and_gnt_with_other_requestors_active ##1 other_req_except_requestorA; endsequence //----------------------------------------------------------------------------------------------------------------------------------------------- //Assertion to check if reqA do not hog the round robin arbiter //----------------------------------------------------------------------------------------------------------------------------------------------- assert_fairness_wrt_requestorA: assert property( @(posedge clk) disable iff(!resetn) (requestorA_req_and_gnt_followed_by_other_req_and_no_bts_seq or multiple_requests_with_requestorA_req_and_gnt_followed_by_other_req_and_no_bts_seq or back_to_back_multiple_requests_active_with_requestorA_gnted_followed_by_other_req_and_no_bts_seq ) |-> other_gnt_except_requestorA && !gntA ) `uvm_info("ARB_ASSERT",$sformatf("Requestor A was previously granted, and not granted again, round robin scheme followed!"),UVM_LOW) else `uvm_error("ARB_ASSERT_ERR",$sformatf("Requestor A was previously granted, and gets granted again, round robin scheme not followed"))
  21. 2 points
    mastrick

    randomize() with inside syntax

    Also, you might want to keep your randomize() call outside the assert(). Otherwise, simulators may not call the randomize at all if you disable assertions (e.g. to temporarily work around a problem). You can assign the return from randomize() to a variable and then assert that variable.
  22. 2 points
    dave_59

    walk thru an enumeration

    You can use a do-while loop: module top; //typedef enum {alpha=0, beta=1, gamma=2, delta=3, epsilon=4} greek; //to show default assignments typedef enum {alpha, beta, gamma, delta, epsilon} greek; greek letters; initial begin $display("****** Walk thru an enumeration example. ***********"); letters = letters.first; do begin $display(" %0d *** %0s", letters, letters.name); letters = letters.next; end while (letters != letters.first); end endmodule : top
  23. 2 points
    The data array will be created implicitly based on the .size(), if it isn't already created, whenever you randomize the class. However, if you allow the simulator to do this implicitly, then you lose the ability to constrain any of the array's variables, which may or may not be something you care about. If you do, then here's how I do this. First, in my class's new function, I new the array to whatever the largest possible size will be. This is important, and perhaps a little wasteful. Second, I constrain the data.size() as you have above. Third, I can then constrain the data bytes, usually using a foreach constraint. When the class is randomized, the data will automatically re-size itself and constrain the data appropriately. So, like this: class pushk_c extends uvm_object; rand int unsigned data_len; constraint data_len_cnstr { data_len < MAX_DATA_LEN; // some parameter or constant } rand byte data[]; constraint data_cnstr { data.size() == data_len; foreach(data[idx]) { data[idx] == idx; } } function new(string name="pushk"); super.new(name); data = new[MAX_DATALEN]; endfunction : new endclass : pushk_c I would prefer not to self-promote, but I will anyway. I demonstrate this a few times in my book: http://tinyurl.com/AdvancedUVM, or for the e-book: http://tinyurl.com/AdvancedUVM-ebook
  24. 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
  25. 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:
×