Jump to content

Philipp A Hartmann

Members
  • Content Count

    533
  • Joined

  • Last visited

  • Days Won

    128

Everything posted by Philipp A Hartmann

  1. Yes. See http://forums.accellera.org/topic/1555-using-tlm2-but-not-generic-payload/ for a previous discussion. Greetings from Oldenburg, Philipp
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. Why not store it in an sc_time variable? sc_core::sc_time now = sc_core::sc_time_stamp(); /Philipp
  10. 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
  11. 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
  12. 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
  13. You still have not configured the correct target machine type for your application. Add '/MACHINE:X64' to your linker command-line. hth, Philipp
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. Your NOC module has indeed many signals. Hopefully, they are already organized as arrays, which you can replace by using appropriate sc_vectors, which can take an explicit name (prefix). As a general recommendation, you should consider to give your channels an explicit name to ease debugging of such errors. A simpler solution is probably to look at the two processes (txProcess, rxProcess) in your Router module. If the problem would be the duplicate binding of a single signal to multiple output ports, the error should have been reported during elaboration already. Instead, the error is raised during simulation, where both processes try to write to the same signal, most likely through the same (in)out port. This should be local enough to find manually. hth, Philipp
  25. If you bind the same interface object (a "single" b_transport) to both target sockets, there is no predefined way to determine the port through which the interface has been called. If you insist on using a plain tlm_target_socket instead of the tagged convenience sockets, you can build the tagging mechanism on your own by implementing a small helper that provides the forward interface (most notably b_transport), stores an ID internally and forwards the call including the ID to the module itself. Not sure, why you would need to reinvent that, though. /Philipp
×
×
  • Create New...