Jump to content

Leaderboard


Popular Content

Showing most liked content since 11/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
    StS

    SCV library installation

    Hi Aixeta, this is already fixed in the upcoming release of the SCV. Meanwhile you can workaround by casting directly to sc_logic: sc_dt::sc_logic_value_t(this->_get_instance()->get_bit(i))
  7. 1 point
    ralph.goergen

    Transaction Data Pointer

    Hi. Normally the initiator is considered as owner of the payload, i.e. he should take care of allocating and de-allocating it. The target should decide how to use the data. If the target wants to keep it/store it, the target should make a copy of the data. In that sense, the transaction is completed when b_transport returns because the initiator transfered it to the target and the target had a chance to handle it. A benefit of this is that you do not need dynamic allocation of the buffer buf. Greetings Ralph
  8. 1 point
    stefans

    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?
  9. 1 point
    Philipp A Hartmann

    Explicit parent object

    Both versions are non-portable, as the SystemC simcontext is not part of the standard either. I am even surprised that the hierarchy_push/pop functions are not restricted (as they should be). So the first solution might in fact break in future versions of SystemC as you shall not mess with the object hierarchy stack yourself. Whether or not the "hierarchy scope guard" can be extended to become a standardized solution will likely require some discussions first, especially how to avoid breaking the object hierarchy. Certainly, this internal hierarchy stack is not something to arbitrarily use from the model side, other than from the sc_module_name usage today. For the particular use case, you can now look into the new "optionally bound convenience sockets" in SystemC 2.3.2, which you can safely leave unbound when not used. An arbitrary number of sockets can be bound to the multi_passthrough_*_socket, without having to do any such magic above. For a generic pattern to request additional structural things to "appear later", you can use an sc_vector with delayed initialization (since SystemC 2.3.2). This is (currently) limited to a single call, but I could envision to extend this to support distributed emplace_back() calls during elaboration. Such an approach would at least restrict the external modification of the hierarchy to much more controllable contexts. Regarding your current use case: How does the destination module actually use these newly added ports/sockets? /Philipp
  10. 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?
  11. 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.
  12. 1 point
    Hi Michael, My understand is that oneToSet also means that writing a 0 has no effect. Best regards, Erwin
  13. 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
  14. 1 point
    Philipp A Hartmann

    unresolved external

    You might want to read this "C++ Super FAQ" entry: https://isocpp.org/wiki/faq/templates#templates-defn-vs-decl Hope that helps, Philipp
  15. 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
  16. 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.
  17. 1 point
    Philipp A Hartmann

    multiple event in next trigger

    I cannot tell, if I understand your question at all. I'll just add the comment that you can use next_trigger(); without any arguments to restore the static sensitivity. Hope that helps, Philipp
  18. 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
  19. 1 point
    Here is an example of connecting serial port model to TCP socket: https://git.greensocs.com/models/tcp_serial
  20. 1 point
    uvm gives you the ability (via vpi) to write using ```uvm_hdl_deposit(string path, value)```
  21. 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
  22. 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
  23. 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
  24. 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
  25. 1 point
    Yes, creating a process with dont_initialize() set just keeps it off the runnable queue until it is triggered by its static sensitivity (or through an explicit reset() on a process handle of it). Without dont_initialize(), static process are marked as runnable during the initialization phase, while dynamic processes are made runnable immediately (i.e. in the current/next evaluation phase). Hope that helps, Philipp
  26. 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
  27. 1 point
    Philipp A Hartmann

    Scope of SC_HAS_PROCESS

    Recommended practice is to put SC_HAS_PROCESS within the scope of the module itself: SC_MODULE(Module) { SC_HAS_PROCESS(Module); // ... }; Hope that helps, Philipp
  28. 1 point
    apfitch

    memory exception

    You should be able to view the Call Stack in Visual C++ - that may give you an idea of exactly where the exception is being thrown, regards Alan
  29. 1 point
    kartikkg

    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.
  30. 1 point
    Hi Ameya, thanks for testing the 2.3.2 public review release! You mentioned, that you saw 15 errors when running the regressions on your platform? Would it be possible to share the list of failing tests and your platform/compiler versions? As you may have seen, I have opened a new topic about your C++ standard question here: Thanks for the analysis and the reporting of the issue. I have prepared a fix for the 2.3.2 final release which avoids the need for the synthesis of the ..._FILTER variable in test script. Instead, the optional filter is substituted directly from within the Makefile and GNU make supports variables starting with a digit. This topic is under discussion since quite some time both inside and outside of Accellera. The best option to contribute patches/fixes to the SystemC proof-of-concept implementations is of course to join the corresponding Accellera Working Groups. If this is not an option, let's continue to use this community forum for public discussions around SystemC and its proof-of-concept implementation. Greetings from Duisburg, Philipp
  31. 1 point
    Hi Ahmed, apologies for the late reply. This is indeed an surprising behavior on your system. It seems the default "--libdir" setting from Autoconf is different on your platform - which is not expected. Can you please post the output of running ../configure --help In order to create the canonical "classic installation layout" of SystemC, you can override the --libdir default via (please note the single quotes): ../configure --libdir='${prefix}/lib' I'll look into the TESTNAME incompatibility for the final 2.3.2 release as well. Thanks and Greetings from Duisburg, Philipp
  32. 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
  33. 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
  34. 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
  35. 1 point
    AmeyaVS

    Delaying simulated execution

    Hello Katang, This has been already discussed previously. Take a look here: -Ameya Vikram Singh
  36. 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.
  37. 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
  38. 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.
  39. 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
  40. 1 point
    deepakkurapati

    Doubt with TLM phase

    see the below image - ref OSCI TLM 2.0 LRM
  41. 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
  42. 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
  43. 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
  44. 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
  45. 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?
  46. 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
  47. 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
  48. 1 point
    apfitch

    primitive and hierarchical channel

    A channel is simply a class that implements a SystemC interface. A primitive channel implements an interface and is derived from from sc_prim_channel, and can thus have access to the scheduler (evaluate update). A hierarchical channel implements an interface and is derived from sc_module, and can thus have all the features of an sc_module (processes, hierarchy etc). There'd be no point in deriving from sc_prim_channel and then not implementing the update/request-update behaviour. If you want a channel that is not a primitive channel, and is not a hierarchical channel, you would typically implement an interface but derive from sc_object. regards Alan P.S. To answer your questions more specifically - request_update and update are not pure virtual, so you could ignore them. Though why would you ignore them? If you don't want them, derive from sc_object instead. A hierarchical channel is derived from sc_module. sc_module does not have request_update/update, so you can't use them.
  49. 1 point
    tudor.timi

    UVM reg model mask

    Hijacking the thread for a bit. Is there a future bug fix release for UVM 1.1 planned? UVM 1.1e maybe for people who don't want to migrate to UVM 1.2 just yet?
  50. 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
×