Jump to content

Philipp A Hartmann

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Philipp A Hartmann

  1. Why not store it in an sc_time variable? sc_core::sc_time now = sc_core::sc_time_stamp(); /Philipp
  2. 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
  3. 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
  4. 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
  5. You still have not configured the correct target machine type for your application. Add '/MACHINE:X64' to your linker command-line. hth, Philipp
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. Sounds like you didn't look up the suggested parts in the standard. /Philipp
  19. The error is caused by the fact that the notify() function of sc_event returns nothing (i.e. 'void'). So you can't return the (non-existing) return value in the marked line above. Secondly, e_HCE is a local variable. You won't be able to trigger any other process by notifying this event. This looks wrong as well. /Philipp
  20. Make sure that you have the "process" function declaration in the body of host_cntrl: class host_cntrl : public sc_module { public: // SC_CTOR(), etc. private: void process(); }; /Philipp
  21. You don't have a member function called 'process' in your 'host_cntrl' class? Hard to tell without actual code. /Philipp
  22. Why don't you ask the process itself? std::cout << std::boolalpha << h1.dynamic() << std::endl; Short answer: Processes created from the process macros SC_THREAD,... are called "unspawned" processes, whereas processes created by sc_spawn are called (surprise!) spawned processes. Unspawned processes are by definition static processes, as the macros can't be used during simulation. On the other hand, spawned processes can be either static or dynamic processes: A dynamic process is created during simulation, whereas a static process is created during elaboration. hth, Philipp
  23. Your problem is not specific to sc_vector, but to C++ in general: You can't initialize a member of an SC_MODULE (or any other C++ class) in the body of the class itself. You need to do it in the constructor, using an initializer list: SC_MODULE(mod) { sc_vector<sc_signal<sc_uint<C_WIDTH> > > sDin; SC_CTOR(mod) : sDin("sDin", C_SIZE) // C++ initializer list { // ... } }; Greetings from Oldenburg, Philipp
  24. Ok, the next step could be to skip simulation and just run the elaboration/initialization via sc_start( SC_ZERO_TIME ); Secondly, you should break on the destructor of mod in the debugger to check whether you can see any indication why the destructor is called twice for the same object. If you have a memory corruption, this might be more difficult to track down. This looks unrelated and is probably caused by accessing unbound ports too early. For now, I think it's more likely that the problem is in your model rather than that there is a bug in SystemC 2.3.1. The sc_vector code didn't change much between 2.3.0 and 2.3.1. This also sounds like an unrelated problem. Good luck in the bug hunting. Feel free to share/post your simplified code if you have further questions. /Philipp
  25. For your convenience, I have created a simple example based on your code at EDA playground (which uses SystemC 2.3.0). Just add/correct the relevant parts and try to reproduce the problem. If the module has just the members you listed, I don't think the problem is related to mod itself. If you add the line after the call to sc_start, it should lead to an error as you can't instantiate additional modules after the end of the elaboration phase. If there is no such error, there may be something else going wrong here (memory corruption?). Do you keep seeing the segmentation fault, if you skip the sc_start call? /Philipp
  • Create New...