Jump to content

Philipp A Hartmann

Members
  • Content Count

    485
  • Joined

  • Last visited

  • Days Won

    117

Everything posted by Philipp A Hartmann

  1. With the plain socket (interfaces), there is no way to determine the socket through which an interface function has been called. There are so called "tagged" convenience sockets provided as part of the TLM utilities (see IEEE 1666-2011, Section 16.1.3, including an example at the end of the section). This topic has been discussed here recently in this thread. hth, Philipp
  2. Philipp A Hartmann

    Overloading/ Registering sc_export

    You can't use the "implement interface and export" idiom in this case, as you obviously can implement each function only once (for each transaction type). You can use a small wrapper instead: SC_MODULE(abc) { typedef int T; sc_core::sc_export<tlm::tlm_analysis_if<T> > exp_1, exp_2; SC_CTOR(abc) : exp_1("exp_1") , exp_2("exp_2") , aw_1(*this,&abc::write_1) // create wrapper for each implementation , aw_2(*this,&abc::write_2) { exp_1(aw_1); // bind wrappers exp_2(aw_2); } private: void write_1( const T& ); // implementation for each export void write_2( const T& ); struct analysis_wrapper : sc_core::sc_object, tlm::tlm_analysis_if<T> { typedef void (abc::*write_func)( const T& ); // pointer to member function with implementation analysis_wrapper( abc& owner, write_func f ) : sc_core::sc_object(sc_core::sc_gen_unique_name("analysis_if")) , this_(owner), f_(f){} void write( const T& v ) { (this_.*f_)(v); } // forward call to registered implementation private: abc& this_; write_func f_; }; analysis_wrapper aw_1, aw_2; }; Hope that helps, Philipp
  3. Philipp A Hartmann

    TLM2 custom playlod

    Yes. See http://forums.accellera.org/topic/1555-using-tlm2-but-not-generic-payload/ for a previous discussion. Greetings from Oldenburg, Philipp
  4. Philipp A Hartmann

    Names of bound TLM-Simple-Sockets

    Yes, sc_interface itself is not derived from sc_object. But the channel that is bound to the port/socket is frequently derived from sc_object. I didn't look up the details in the standard, but to me it may be a reasonable assumption that the bound object is indeed a proper part of the SystemC object hierarchy. Indeed, the current implementation of the simple sockets use internal classes not derived from sc_object to provide the interface implementations. To me, this is at least an inconvenience for use cases like yours. I'll take this to the LWG/TLMWG for discussion. You may still be able to "lookup" the correct socket by traversing the object hierarchy (5.16.7) looking for candidate sockets and comparing the original result of 'get_interface()' with the interfaces of the candidates. Or derive your own socket and override the bind() function to store the name. Make sure to call the base-class bind() to actually perform the binding. /Philipp
  5. Philipp A Hartmann

    UVM and reserved keywords in C++

    Sure, it's not possible to avoid such issues for arbitrary future languages. On the other hand, we should still address the languages that have a UVM implementation being worked on or are likely to see such an implementation in the future. Hopefully, people with interest in a particular language can do the check for potential conflicts and report back during the IEEE standardization process. Yes. The process can't be fully automated. The "grep -w" suggestion from above can serve as a simple starting point to identify possible conflicts, mainly regarding the convenient "word matching" functionality to avoid false negatives where the keywords are only a part of identifiers. You can easily exclude implementation files. Comments are not filtered either. Still, the resulting list is hopefully short enough to be processed manually processed for "real" conflicts in the public/official API. /Philipp
  6. Philipp A Hartmann

    Names of bound TLM-Simple-Sockets

    You can use a dynamic cast to access the channel object bound to the port/socket: sc_object * obj = dynamic_cast<sc_object*>(socket.get_interface()); std::cout << obj->name() << std::endl; Greetings from Oldenburg, Philipp
  7. Philipp A Hartmann

    UVM and reserved keywords in C++

    It should be possible to use "grep -w" (word match) for this purpose: grep -rwE '(catch|delete|register|...)' /path/to/uvm/src with "..." being all C++ keywords that are not already keywords in SV. The same could be done for e, VHDL, Python, Java, ... /Philipp
  8. Philipp A Hartmann

    UVM and reserved keywords in C++

    No, this is not possible as C++ keywords (like catch, delete, register) are not part of scoping rules. They are part of the grammar instead. Therefore, I would second to rename these functions in UVM during the IEEE standardization. /Philipp
  9. Philipp A Hartmann

    multiple b_transport methods

    I'm not sure, if I understand the question right. How do you use 'b_transport' without sockets? Of course, technically, you can just use sc_core::sc_port<tlm::tlm_blocking_transport_if<my_payload> > > my_transport_port; but the you are quite far away from TLM-2.0. ;-) Sockets (or ports and exports) in general are a good idea to separate communication and computation. This improves the modularity of your design. Using tlm_analysis_ports for data communication (in the modelled system) is probably not what you want either. But on the other hand, I don't know the details of your use case. /Philipp
  10. You can use b_transport and the convenience sockets with your custom payload class. First, you'll need the "my_protocol_types" traits class earlier in this thread. Secondly, due to the blocking/non-blocking conversions, the simple sockets depend on some features of the generic payloads internally (e.g. the memory management and extensions). If you don't want to use this functionality, you can provide dummy implementations for these GP parts. If you want the B/NB conversion to work, you should implement them properly, e.g. by reuising the relevant parts of the tlm_generic_payload class. Instead, I would suggest to use the passthrough sockets, that don't perform any protocol conversions, see Section 16.1 in IEEE 1666-2011: SC_MODULE(my_module) { tlm_utils::passthrough_target_socket<my_module,32,my_protocol_types> socket; // ... SC_CTOR(my_module) { socket.register_b_transport(this,&my_module::my_b_transport); } void my_b_transport(my_item& trans, sc_time& delay) { // ... } }; In general, TLM-2.0 is about interoperability. It is meant to cover a wide range of modeling requirements across tool and model providers. If you don't care about interoperability with third-party models, you're free to ignore many of the rules (and simply return an error for unsupported features, like byte enables, DMI, etc.). But I agree, the API and all details of the TLM-2.0 rules are quite complex and not made for beginners. Model writers often rely on in-house or vendor-specific convenience layers on top. hth, Philipp
  11. Philipp A Hartmann

    error:storing sc_time_stamp() ??

    Why not store it in an sc_time variable? sc_core::sc_time now = sc_core::sc_time_stamp(); /Philipp
  12. Philipp A Hartmann

    (E112) Port is not bound

    You've not shown the constructor of your RF module. Make sure not to access the "fir_instr" port from there. If you need to perform some initialization after the port has been bound, have a look at the "end_of_elaboration" or "start_of_simulation" callbacks. Greetings from Oldenburg, Philipp
  13. Philipp A Hartmann

    multiple b_transport methods

    I'm assuming, it is ok for you to have different sockets for these two b_transport functions. The simplest solution is to use two tlm_utils::simple_target_socket instances and just register different functions for each of those: SC_MODULE(target) { tlm_utils::simple_target_socket<target> socket1; tlm_utils::simple_target_socket<target> socket2; SC_CTOR(target) : socket1("socket1") , socket2("socket2") { socket1.register_b_transport(this, &target::first_b_transport); socket2.register_b_transport(this, &target::second_b_transport); } void first_b_transport( tlm::tlm_generic_payload &, sc_core::sc_time & ); void second_b_transport( tlm::tlm_generic_payload &, sc_core::sc_time & ); }; Alternatively, you can use tagged sockets and dispatch to different implementations based on the ID parameter. hth, Philipp
  14. The correct name of the configuration type for 64-bit differs between the MSVC toolchain versions/variants. Try one of 'amd64' or 'x86_amd64'. See READMEcommandlinemsvc.txt in examples/tlm/build-msvc. /Philipp
  15. You still have not configured the correct target machine type for your application. Add '/MACHINE:X64' to your linker command-line. hth, Philipp
  16. My guess would be, that you didn't configure your application project in MSVC to be built as 64-bit application. You need to (add and) select the 'x64' platform and make sure that the settings are consistent with the SystemC library project. You can use the project files for the examples as a starting point. Update: I should read the question properly. Please forget the above answer. Using the command-line requires to select the "correct" set of tools for the platform you want to use. Have a look at the TLM examples (examples/tlm/build-msvc), which provide command-line Makefiles for MSVC as well. Most importantly, have a look at "vsvars.bat" in this folder, which can be used to choose the correct MSVC command-line configuration. You can then derive additional command-line settings from the "Makefile.config" file in the same directory. /Philipp
  17. Philipp A Hartmann

    Where is sc_link_mp defined?

    sc_link_mp, sc_inslave, sc_outmaster are elements of the old "SystemC Master-Slave library". This library has been an early approach to transaction-level modeling in SystemC. The original implementation will most likely not compile with IEEE 1666-20xx standard-compliant simulators. For high-level modeling, you should look into the TLM-1 and TLM-2 APIs, that are now part of the IEEE standard for SystemC. /Philipp
  18. Philipp A Hartmann

    Why is fixed point number not recognized by compiler?

    If you find an answer to your question by yourself, please don't drop the original question and just add an answer to your own post. This lets other users benefit from the discussion. Thanks, Philipp
  19. Philipp A Hartmann

    When the method to_default_time_units() returns 0?

    I would use the clock generator coming with SystemC by instantiating an sc_clock (see Section 6.7 in IEEE 1666-2011): sc_clock clk( "clk" // name , sc_time(100, SC_NS) // period , 0.5 // duty cycle , sc_time(100, SC_NS) // start time , true ); // start with positive edge I've selected the parameters guessing from your code snippet. In "your" code, the first rising edge seems to occur at 100ns (start time). Play with the values as you need them. You can then bind this clock to any sc_in<bool> port in your system. /Philipp
  20. Philipp A Hartmann

    Where is declared SC_OFF?

    SC_ON, SC_OFF are related to "floating-point cast switches". You likely don't need to worry about these, if you don't know what problems these intend to address. Otherwise, please refer to Sections 7.10.7, 711.5 of IEEE 1666-2011. Syntaxwise, you currently try to invoke the function call operator on the sc_ufixed variable d (with an incompatible parameter). What do you intend to achieve? Do you want to assign a value? /Philipp
  21. It should. You should see a second "func2 start" line. Please post a complete example. Is there a difference between SystemC 2.3.0 and 2.3.1? Which platform/what compiler (flags)? /Philipp
  22. Philipp A Hartmann

    When the method to_default_time_units() returns 0?

    First of all, all "time units" related functions are deprecated and should not be used. These functions predate the IEEE standard for SystemC. That said, at the beginning of the simulation, sc_time_stamp() is SC_ZERO_TIME (i.e. 0). As a result, the conversion to "default time units" is zero as well. /Philipp
  23. As the original error message says, you are not supposed to disable() a process that is within a timed wait (i.e. wait(xx,SC_NS); in your case). See Section 5.6.6.2 of IEEE 1666-2011. Moreover, since your func2 process has no static sensitivity, the process will not run again after it is enabled, unless it is explicitly reset. See 5.6.6.2 again, quoting: If you want to enable/disable a process, the target process should be sensitive to events, instead of using timed waits itself. /Philipp
  24. Although Cygwin is not among the most widely tested platforms for the Accellera SystemC proof-of-concept simulator, the current version 2.3.1 has been tested successfully on Windows 7 SP1 (WoW64), (Cygwin 1.7.17)GNU C++ compiler versions gcc-3.4.4 through gcc-4.3.4 (x86)Please provide at least SystemC version platform (version), compiler (version), flags compile/runtime warnings and errors AFAIK, the _WIN32 macro tells that you're using the Windows API. Using the Windows API implies that you have support for __int64 and the like. Do you define _WIN32 explicitly on the command-line? Why? Cygwin does not provide this symbol by default. Greetings from Oldenburg, Philipp
  25. It's called "direct memory interface", because it's a direct access to a target's memory range. The target has no way to observe accesses from initiators to the currently allowed DMI ranges. If the target requires to observe such accesses, you should not grant DMI access for these address ranges during the relevant communication states/phases. Usually, DMI is preferred for the plain memory parts of the target's interface, while (control) registers often require explicit TLM transactions for that reason. hth, Philipp
×