Jump to content

Philipp A Hartmann

Members
  • Content Count

    490
  • Joined

  • Last visited

  • Days Won

    118

Everything posted by Philipp A Hartmann

  1. Philipp A Hartmann

    E549, uncaught exception bad_alloc when invoking sc_spawn()

    Oh, I should have mentioned that you can try to build your SystemC kernel with a Pthread threading implementation: ../configure [...] --enable-pthreads The stack size requirements might be different there. Alternatively, you can use a MinGW32 compiler (http://mingw-w64.sourceforge.net/), which then uses the native Windows threading facilities (WinFiber) under the hood. hth, Philipp
  2. Philipp A Hartmann

    E549, uncaught exception bad_alloc when invoking sc_spawn()

    Short answer: You can't. The current proof-of-concept simulator employs a stack protection mechanism to detect stack overflows by using the OSs memory protection mechanisms. This requires an additional memory page (as a red zone) after the "real" stack. As you have seen, this requires the minimum stack size to exceed a certain value. 0x1000 is certainly too small here. I would have expected that 0x10000 could work, but this seems not to be the case. If your threads are so small and simple, maybe you can port them to SC_METHODs. Alternatively, you can try to switch to a 64-bit OS. /Philipp
  3. Philipp A Hartmann

    E549, uncaught exception bad_alloc when invoking sc_spawn()

    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
  4. Philipp A Hartmann

    Generate a shared-library containing a SystemC program

    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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. You still have not configured the correct target machine type for your application. Add '/MACHINE:X64' to your linker command-line. hth, Philipp
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
×