Jump to content

Leaderboard


Popular Content

Showing most liked content since 09/22/2016 in all areas

  1. 2 points
    Hello @Roman Popov, You can have a look here: Hope it helps. Regards, Ameya Vikram Singh
  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
    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.
  4. 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
  5. 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
  6. 1 point
    Any eventual copy returned from read() by value will never be optimized away, as the source location continues to exist in the signal. The simplest solution is to change your signal converter as follows (untested): template <typename Treal, typename Tcasted> class signal_interface_converter : public sc_core::sc_signal<Treal> , public sc_core::sc_signal_in_if<Tcasted> // only read allowed { typedef sc_core::sc_signal<Treal> real_type; public: explicit signal_interface_converter(const char* nm) : real_type(nm), casted_val() {} const Tcasted &read() const override { return casted_val; } private: void update() override { real_type::update(); casted_val = static_cast<Tcasted>(real_type::read()); ] Tcasted casted_val; }; So the idea is basically to leverage the update phase to update the casted value. If the above doesn't work due to read() overloads based on the return type only, you may need to wrap it differently to separate the two conflicting interfaces (e.g. by using an internal signal with an overridden update() function, triggering the update of the casted value in the converter). Hope that helps, Philipp
  7. 1 point
    My SystemC-Code is using messages of severity "Error" to intentionally throw exceptions. Suddenly I realize that no longer exceptions are thrown. Analyzing this issue, I targeted the function in my code "scv_random::seed_monitor_on(true, "../../Source/seedfile.txt");" to be the cause of this. For my current scenario I screwed up the path to the "seedfile.txt" which results in an error in "seed_monitor_on()". In this "seed_monitor_on()" calls the following: cannot_open_seed_file() -> message() -> set_actions(SCV_ERROR,SCV_LOG|SCV_DISPLAY|SCV_CACHE_REPORT) Conclusion at it seems to me: In case of a file not found "seed_monitor_on()" removes throwing off exception ("SC_THROW") in ALL(!) cases of messages with severity "Error". I would consider this to be an unwanted global side effect and probably a bug. Or?
  8. 1 point
    You would need to describe your actual question in a bit more detail. Is it about the logic inside the target (i.e. not performing the write)? Sure, you can check the state of the control bit in b_transport before processing the command. Is it about informing the initiator that this happened? Then you need to either use the response status or an extension. /Philipp
  9. 1 point
    I've needed it for test environment modeling purposes, not for synthesis. Delta delay problems (also known as Shoot-thru) are possible in synthesizable SystemC. Common case is when you have a clock gate that inserts a delta delay into a clock signal distribution network. However in SystemC it is solved in a different way: Instead of delaying all assignments, you use immediate notifications inside clock signal, so that processes sensitive to gated clock are executed in the same delta cycle with processes sensitive to ungated clock.
  10. 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
  11. 1 point
    Here is an example of connecting serial port model to TCP socket: https://git.greensocs.com/models/tcp_serial
  12. 1 point
    uvm gives you the ability (via vpi) to write using ```uvm_hdl_deposit(string path, value)```
  13. 1 point
    Philipp A Hartmann

    SystemC Evolution Day 2017

    SystemC Evolution Day 2017 Workshop on the evolution of SystemC standards Wednesday, October 18, 2017 Munich, Germany Summary SystemC Evolution Day is a full-day technical workshop on the evolution of SystemC standards to advance the SystemC ecosystem. This is the second event after a successful first edition in May 2016. In several in-depth sessions, current and future standardization topics around SystemC will be discussed in order to accelerate their progress for Accellera and IEEE standard’s inclusion. SystemC Evolution Day is intended as a lean, user-centric, hands-on forum bringing together the experts from the SystemC user community and the Accellera Working Groups to advance SystemC standards in a full-day workshop. Date / Time: October 18, 2017 (day after DVCon Europe 2017) | 10:00am - 6:00pm Location: Technical University of Munich, City Campus | Arcisstraße 21, 80333 Munich, Germany Registration: Required, but free of charge. Register here > Submissions / Questions: Email systemc-evolution-day@lists.accellera.org Organization Team: Philipp A Hartmann, Intel; Oliver Bell, Intel; Martin Barnasconi, NXP; Matthias Bauer, Infineon; Thomas Kruse, Infineon Call for Contributions In the morning, a series of lightning talks are planned, covering concrete, but smaller standardization proposals as well as introducing new standardization needs around SystemC. For each of these short presentations, time for an interactive discussion will be included to gather feedback and support and for identifying the next steps towards standardization. In the afternoon, in-depth topic sessions are planned again, enabling a 90-minute detailed and interactive technical discussion on the most significant ongoing and future topics around SystemC standardization. If you are interested in championing a topic for an afternoon session or presenting your favorite extension to the SystemC community as part of a lightning talk, please send a title and abstract with up-to 100-words (lightning talks) or 400 words (topic session) by end of June to systemc-evolution-day@lists.accellera.org. You will receive a notification of acceptance by September at the latest. Important dates: June 30, 2017 – Proposal abstract submission deadline September 1, 2017 – Notification of acceptance September 15, 2017 – Announcement of the program
  14. 1 point
    AmeyaVS

    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
  15. 1 point
    Hi Mr SystemCInDepth, I think it's important to realise that SC_CTHREAD is special, in that the specified sensitivity is a clock (the rising or falling edge event of a bool or sc_logic). There's no such thing as a "clock" for SC_METHOD and SC_THREAD - just events on channels such as sc_signal, sc_fifo, or any other channel that implements an event. So I would not say because an SC_METHOD or an SC_THREAD does not have a clock. That's what Philipp meant when he said Does that make it clearer? regards Alan
  16. 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
  17. 1 point
    maehne

    Compiling SystemC on ARM

    Thanks for the feedback on how to make SystemC work on the aarch64 platform! At least another party has expressed its interest for support of this platform and offered patches, which are currently under review in the Language Working Group. Regards, Torsten
  18. 1 point
    Hello @katang, The error spawns from not specifying the namespace resolution correctly. Following code compiles without errors: NAME.h: #ifndef NAME_H_ #define NAME_H_ #include <systemc> SC_MODULE(NAME) { SC_CTOR(NAME); }; #endif // NAME_H_ NAME.cpp: #include "NAME.h" SC_HAS_PROCESS(NAME); NAME::NAME(sc_core::sc_module_name nm) //< Added sc_core namespace resolution. : sc_core::sc_module(nm) //< Added sc_core namespace resolution. {} Regards, Ameya Vikram Singh
  19. 1 point
    kurtlin

    ERROR IN NCSIM Simulation -E,CUVMUR

    Hi Venkatesh, You can check the details of this message via this command: nchelp ncelab CUVMUR I think you did not compile rcd2_top befor gen_ddr4_rcd_chip in your environment. Thanks, Kurt
  20. 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
  21. 1 point
    Side note: You can't use virtual inheritance with SystemC modules. See the following thread for a related discussion: Your example doesn't require this, so it should be fine to simply drop the virtual keyword in the sc_module inheritance. Hope that helps, Philipp
  22. 1 point
    AmeyaVS

    Delaying simulated execution

    Hello Katang, This has been already discussed previously. Take a look here: -Ameya Vikram Singh
  23. 1 point
    Your problem is not SystemC-specific, as you are not following basic rules of C++ programming: To use classes of SystemC like sc_core::sc_interface or sc_core::sc_module, you have to #include the respective header (in our case <systemc>) before. You haven't done so in your headers comm_interface.h and comm_channel.h Also, your headers comm_interface.h and comm_channel.h seem to lack #include guards, which cause the type redefinition errors. I encourage you to not use the header <systemc> and not <systemc.h> to avoid public namespace pollution. Then, you have to prefix most SystemC classes with the sc_core:: namespace prefix. In function scope, you can avoid this by adding "using" declarations for the symbols/namespaces you plan to use in the current scope.
  24. 1 point
    AmeyaVS

    SystemC 2.3.2 Public Review Now Open

    Hello, Also hit a build issue when mixing different compiler standard compiler flags: The build error: SystemC review error: when building example using c++11 option and compiler supports: C++14 also. CMakeFiles/systemc.run.dir/src/main.cpp.o: In function `__static_initialization_and_destruction_0': /home/ameya/sysc2.3.2_rew/include/sysc/kernel/sc_ver.h:179: undefined reference to `sc_core::sc_api_version_2_3_2_cxx201103L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201103L(sc_core::sc_writer_policy)' Compiler used g++ 6.3 Using same compiler to build systemc-2.3.1a results in no issues, also when mixing C++ standard compiler flags to build SystemC models. While building the SystemC_2.3.2_draft one has to maintain the C++ standard compiler flags(-std=c++11 or -std=c++14), that is supported by the g++ compiler by default and any project using overridden standard compiler flags also needed to be updated to to default compiler standard flags. Here are the differences in the symbols generated by the same compiler over different versions of systemc: SystemC-2.3.1a: (Using g++ 6.3.0) 000000000000023e T sc_core::sc_api_version_2_3_1<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_1(sc_core::sc_writer_policy) 000000000000023e T sc_core::sc_api_version_2_3_1<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_1(sc_core::sc_writer_policy) 000000000000002c b sc_core::sc_api_version_2_3_1<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_1(sc_core::sc_writer_policy)::default_writer_policy_config 000000000000002a b sc_core::sc_api_version_2_3_1<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_1(sc_core::sc_writer_policy)::default_writer_policy_config_seen SystemC-2.3.2-draft review:(Using g++ 6.3.0) 00000000000007d0 T sc_core::sc_api_version_2_3_2_cxx201402L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201402L(sc_core::sc_writer_policy) 00000000000007d0 T sc_core::sc_api_version_2_3_2_cxx201402L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201402L(sc_core::sc_writer_policy) 0000000000000028 b sc_core::sc_api_version_2_3_2_cxx201402L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201402L(sc_core::sc_writer_policy)::default_writer_policy_config 000000000000002c b sc_core::sc_api_version_2_3_2_cxx201402L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201402L(sc_core::sc_writer_policy)::default_writer_policy_config_seen Can anyone comment why C++ standard specific API specs are required? For now I can circumvent the issue while setting either no compiler standard flags, or commenting out the compiler standard is passed into the build system. Is the SystemC library will be following this trend to build different version supporting different compiler standard flags? Note: As per cursory look into the source code I don't see any other API dependency to have information about the C++ standard being used to build and compile the SystemC library and the SystemC models. Would like to hear community members thoughts on this? Best Regards, Ameya Vikram Singh
  25. 1 point
    @daveW you can tryout the SystemC 2.3.2 draft release which fixes most of the issues while building under C++11/C++14 compilers. Have a look here: Regards, Ameya Vikram Singh
  26. 1 point
    sraman

    SystemC 2.3.1 includes TLM 1.0

    Hi, TLM 1.0 still a current std. it is supporting/providing low level interfaces for transaction level modeling(like packets/ not pin level) . It is widely using in SV-OVM based Env. TLM 1.0 was not designed specifically for bus modeling or interoperability. Please refer to the following page. http://accellera.org/downloads/standards/systemc thanks, Sudha.
  27. 1 point
    apfitch

    Priority and PEQ

    I guess first you'd need to add an attribute (extension) to the generic payload to represent the priority. Then you could write a variant of the PEQ which takes into account that priority. regards Alan
  28. 1 point
    AmeyaVS

    TLM sockets

    Hello Shashidhar, You can look at the heading "Interoperability and the Base Protocol" on the same page on the Doulos TLM Tutorial page: https://www.doulos.com/knowhow/systemc/tlm2/tutorial__1/ Hopefully it helps, let me know. Regards, Ameya Vikram Singh
  29. 1 point
    AmeyaVS

    TLM sockets

    Hi, You can look into the previous discussion on the same. http://forums.accellera.org/topic/1603-simple-sockets-and-tlm-sockets/ You can also refer the Doulos TLM tutorial here about the tlm_utils. Regards, Ameya Vikram Singh
  30. 1 point
    How about using delta cycles? Their main reason is to bring determinism into concurrent systems. When you notify the event for the next delta cycle with e.notify(sc_core::SC_ZERO_TIME), then it will definitely see all transactions that happened in this delty cycle. Greetings Ralph
  31. 1 point
    On modern GCC versions (starting with 5.x), you the binary interface changed between C++03 and C++11 mode. You need to build your SystemC library with the same compiler (settings) to get the C++11 version of the functions. Hope that helps, Philipp
  32. 1 point
    Hi. If you want to pass arguments to the constructor of the elements of an sc_vector, you need a custom creator. See SystemC LRM IEEE:1666 Section 8.5.5 for details and examples. A very easy way to realize custom creator by using a Lambda function is presented here: https://www.researchgate.net/publication/284731273_Automated_SystemC_Model_Instantiation_with_Modern_C_Features_and_sc_vector Greetings Ralph
  33. 1 point
    The regression suite, files systemc-regressions-2.3.1a/tests/systemc/datatypes/fx/constructors/array.cpp systemc-regressions-2.3.1a/tests/systemc/datatypes/fx/fast_constructors/array.cpp systemc-regressions-2.3.1a/tests/systemc/datatypes/misc/test02/test02.cpp invoke undefined behaviour by converting out-of-range doubles to unsigned integers directly. This is undefined in the C++ standard See http://stackoverflow.com/a/4752947/1763356 for further information. This happens multiple most prominently in the code sc_fxval *b = new sc_fxval[4]; b[0] = (ushort)-1; for (i = 1; i < 4; ++i) b[i] = (ushort)(b[i-1] * i * -1); where negative doubles are converted to unsigned shorts, because sc_fxval only has conversions to double. It is unclear whether the test is correct and sc_fxval wrong, or vice-versa. If the later, one can avoid undefined behaviour by indirecting through a sufficiently large signed type. sc_fxval *b = new sc_fxval[4]; b[0] = (ushort)-1; for (i = 1; i < 4; ++i) b[i] = (ushort)(int64)(b[i-1] * i * -1); I was caught by this issue when testing a build of SystemC for AArch64, as part of a port I am making. As an aside, how (and where) should I attempt to upstream my port when it is ready?
  34. 1 point
    you cannot read a value from a TDF signal. Access to TDF signals is only possible via TDF ports in the context of aTDF module inside the context of a processing method (see LRM or User guide). It's why the schedule (underlying equation system) is setup during elaboration and during simulation the TDF time is not inline with the SystemC time - a read access to a TDF signal out of context cannot know which value from the buffer has to be read - only the connected and thus scheduled TDF module has this information.
  35. 1 point
    Hi Ralph, I agree, that the change in 2.3.1 is in violation of IEEE 1666-2011. And this needs to be fixed for sure. For 2.3.2, it's currently most likely that we just restore the original behavior. On the question of how to simplify the usage of sc_bitref in boolean contexts, we might also look into "explicit conversion to bool", see for example http://stackoverflow.com/questions/6242768/is-the-safe-bool-idiom-obsolete-in-c11. This needs further exploration and discussions in order to avoid escapes as in 2.3.1. This could be added to either sc_bitref<sc_bv_base> (sc_bitref<sc_lv_base>) (sc_logic) For the first option, I see the least risk of breaking the 1666-2011 compliance. The other two options could have more unwanted side-effects. The IEEE 1666-2011 sc_bit_ref template argument looks like an oversight to me. Will add this to the errata for review in IEEE later. Thanks and Greetings from Duisburg, Philipp
  36. 1 point
    A well known SystemC problem. Unfortunately you will have to create SC_METHOD that will divide your ins port into multiple signals on range basis.
  37. 1 point
    saleem145

    Getting started

    Hello, Here is what I would like to. Design a library of modules. Each module will be implemented in systemc. For this I need the systemc libraries, a text editor and compiler. So easily doable. Next step I would like to design a system by connecting up different modules in my library. For this I need some kind of application which has a graphical user interface. Question is what application can I use for this purpose? Ideally I want something open source and free but it does not have to be. Thanks, Saleem
  38. 1 point
    maehne

    how to get the time of the next event

    Have a look at clause 4.5.7 "Functions to detect pending activity" in the IEEE Std 1666-2011 SystemC LRM. The functions described in this clause should allow you to implement the functionality you are looking for.
  39. 1 point
    maehne

    SystemC with noexcept (c++11)

    Hello Sumit, my advice would be to not mark member functions as noexcept that contain calls to SystemC functions or a library that does throw. Otherwise, any uncaught exception leaving the context of the function noexcept-declared will yield a call to std::terminate(). Yes, annotating functions with noexcept may enable the compiler to do additional optimization. However, many modern compilers already generate code, which doesn't has a performance penalty in the path where no exception occurs. In case an exception occurs, you won't care about the performance penalty caused by the occuring stack unwinding. However, you do usually care about being able to deal with exceptions in places, where you have enough knowledge to properly deal with problem. This is not necessarily in the function you declared noexcept. So, in many cases you probably won't gain much by declaring your member functions noexcept. Still, there are certain places, where declaring functions as noexcept promises more advantages: in particular, move operations, swap, memory deallocation functions, and destructors. This is explained in much more detail in Item 14 of Scott Meyer's book "Effective Modern C++". The SystemC standard still is based on C++'03 and so is the proof-of-concept implementation provided by Accellera. It will require considerable work to move SystemC to actively use C++'11/14/17 features. The topic is on the agenda of the Language Working Group, as the discussion regarding this topic showed during the SystemC Evolution Day in Munich in May. Contributions through participation in the respective working groups are certainly welcome. Finally, to give you some more solid information regarding best practices for using noexcept, I would like to point you to: Scott Meyers "Effective Modern C++", Item 14 "Declare functions noexcept if they won't emit exceptions.", O'Reilly, 2015. Bjarne Stroustrup: "C++'11 FAQ: noexcept -- preventing exception propagation", 2015. Andrzej Krzemieński: "noexcept — what for?", Andrzej's C++ blog, 2014-04-24. Andrzej Krzemieński: "Using noexcept", Andrzej's C++ blog, 2011-06-10. Best regards, Torsten Maehne
  40. 1 point
    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.
  41. 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.
  42. 1 point
    A.Elgogary

    Mixing Systemc with Systemc AMS

    I have been tring to connect Systemc Modul with SC_METHOD to other parts which is TDF modules, but keep receiving different errors in ports and signals connection , Can some clarify how to do it? Controller have inputs from TDF and sends outputs to it (Systemc) to (Systemc-AMs) TDF
  43. 1 point
    A number of universities use SystemC: From the Ground Up, and I am told they are reasonably successful. I am slightly biased as I am one of the authors. I do lecture occasionally at the university level.
  44. 1 point

    Version

    3,822 downloads

    This file, when sourced via your .vimrc file, highlights the HDL (Verilog, SystemVerilog) and Methodology layer (UVM) keywords in the vim editor.
  45. 1 point
    karthickg

    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!
  46. 1 point
    You need to create the ports while the correct instantiation context is established. Since you can't do so during construction of the module, you need to defer it to the 'before_end_of_elaboration()' callback of SystemC. For this matter, you need to temporarily store the signals, in e.g. a vector of pointers. See the following (untested) sketch: SCA_TDF_MODULE(waste) { sca_tdf::sca_in<double> in; // Main 'in' port sc_core::sc_vector< sca_tdf::sca_in<double> > secondary_ins; // prefer sc_vector over vectors of pointers SCA_CTOR(waste) : in("in"), secondary_ins( "secondary_in" ) { } // temporarily store signal pointer void bind(sca_tdf::sca_signal<double> &s) { sc_assert( sc_core::sc_get_status() == sc_core::SC_ELABORATION ); secondary_signals.push_back( &s ); } void processing() { //... } private: // actually do the binding virtual void before_end_of_elaboration() { // create the secondary ports secondary_ins.init( secondary_signals.size() ); // bind the ports for( std::size_t i = 0; i < secondary_ins.size(); ++i ) secondary_ins[i].bind( *secondary_signals[i] ); // cleanup temporary signals secondary_signals.clear(); // be nice and call the base class callback sca_tdf::sca_tdf_module::before_end_of_elaboration(); } // temporarily hold additional inputs during elaboration std::vector< sca_tdf::sca_signal<double>* > secondary_signals; }; Hope that helps, Philipp
  47. 1 point
    apfitch

    simple sockets and TLM sockets

    Hi Cam, the simple_sockets behave in the same was as the standard sockets, in the sense that an initiator may *call* the four functions (b_transport, nb_transport_fw, get_direct_me_ptr, transport_dbg) and the target *must* implement those functions. On the reverse path the target may *call* nb_transport_bw and invalidate_direct_mem_ptr, and the initiator implements them. The only difference with the simple sockets is that they have the bodies of the functions for you. In other words the simple_target_socket implements the tlm_fw_transport_if, it contains function bodies for b_transport, nb_transport_fw, get_direct_mem_ptr, and transport_dbg. However to tell those functions exactly what to do, you register your *own* function with the required behaviour. To do this, you call register_b_transport etc. So if the initiator calls b_transport in the target with a simple socket, the b_transport function *in the simple socket* is called. That then in turn calls the function you registered with b_transport. That compares to the standard sockets, where the implementation of b_transport is *in the target* not *in the simple target socket*. I hope that's a bit clearer, regards Alan
  48. 1 point
    We are using OVM until yesterday for a big Soc verification. The top level Soc OVM ENV contains individual IP level OVM components (OVC's) and we are planning to migrate to UVM soon. Out of the 10 IP OVC's, one of IP components is migrated to UVM. Can we instantiate this IP UVC into Soc level OVM ENV and test it? Is it practically possible? do we need to wait until all the IP components are migrated to UVC's in order to change the Soc ENV also to a UVM ENV? Please suggest. Thanks in advance, Pradeep
  49. 1 point
    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
  50. 1 point
    krb

    VCS MX and UVM

    Hi, Trying to compile my mixed vhdl/ SV-UVM code with vcs. dut is in vhdl and uvm testbench is in SV. I am using the multi-step analyse/eloborate method and have problem here. 1) vhdlan -full64 -work work -file ${vhdl_f} -l compile.vcslog -- works fine 2) vlogan -ntb_opts uvm-1.1 -full64 -work work -sverilog -lca -f ${filelist} -l compile.vcslog reports this error: Error-[sV-LCM-PND] Package not defined my_pkg.sv, 141 my_pkg, "uvm_pkg::" Package scope resolution failed. Token 'uvm_pkg' is not a package. Originating module 'my_pkg'. Move package definition before the use of the package. 3) vcs -full64 -work work -time_resolution 1ps +vpi +vcsd +memcbk -sverilog -lca -ntb_opts uvm-1.1 +define+UVM_TR_RECORD my_tb_top -l compile.vcslog -- didn't reach here. How can I fix these issues. BTW the same code works in IUS/irun. Is there a single step analyse/elaborate method for compiling mixed hdl ? What is the -lcs option here, I copied it from one of the examples. Thanks for any help
×