Jump to content

Philipp A Hartmann

  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Philipp A Hartmann

  1. No. In SystemC 2.3.1, the platform-specific defaults are defined in sc_thread_process.h. To obtain the default value used on your platform, you can query the SC_DEFAULT_STACK_SIZE constant in your application. Use sc_spawn_options, see Section 5.5 in IEEE 1666-2011: sc_spawn_options opt; opt.set_stack_size(0x10000); sc_spawn( func, "func", &opt ); Yes, on 32-bit OSs, the overall memory space for user applications is usually limited to 2GB (on Windows) and 3GB (on Linux). On 64-bit OSs, this limitation is lifted. hth, Philipp
  2. In general, it is not different from a classical C++ shared library. The details can't be answered without a more detailed question and/or problem description. If your "SystemC program" contains an sc_main, you can afterwards call "sc_elab_and_sim" from your scripting language to setup the kernel and the simulation model. See Section 4.3.2 in the IEEE 1666-2011 standard. hth, Philipp
  3. The file visualc.hpp is part of the external Boost library, where a rather old version is partially packaged with SystemC. The documentation in the README file is correct. You can safely ignore the warning during the build. The version check inconsistency has been fixed in SystemC 2.3.1 (among many other things). I would encourage you to update to the latest version. Greetings from Oldenburg, Philipp
  4. 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
  5. 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
  6. Yes. See http://forums.accellera.org/topic/1555-using-tlm2-but-not-generic-payload/ for a previous discussion. Greetings from Oldenburg, Philipp
  7. 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
  8. 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
  9. 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. Why not store it in an sc_time variable? sc_core::sc_time now = sc_core::sc_time_stamp(); /Philipp
  12. 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. 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. 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. 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. 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. 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. 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 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 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
  • Create New...