maehne

Members
  • Content count

    121
  • Joined

  • Last visited

About maehne

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male
  • Location
    Burgdorf, Switzerland

Recent Profile Visitors

276 profile views
  1. SystemC currently does not support to do several distinct simulations from within the same application process. Once elaboration is finished, you cannot instantiate new modules, ports, and channels, as they would modify the design hierarchy. Furthermore, after an sc_stop(), it is an error to call sc_start() again, see IEEE Std 1666-2011, clause 4.5.3: "It shall be an error for the application to call function sc_start after function sc_stop has been called." You may be able to arrange for your design hierarchy to stay constant across all simulation runs. In that case, you could make changes to the parameterization of the module instances in your hierarchy to modify stimuli and behavior each time an sc_start() hands back control to your sc_main(). If you need to do several simulations with divergent design hierarchies, you will have to launch an own process for each simulation case. You could store the parameters for the different simulation runs in one or more configuration files and pass this config file plus possible additional parameters as command line arguments to your SystemC application to easily switch between the different cases. A script file can then automate the execution of all the different necessary simulations.
  2. When implementing your own memory manager for TLM payload objects, you have to follow the rules laid down in IEEE Std 1666-2011 clauses 14.5 and 14.6. When you are leaking memory it is because your new operation to allocate a new tlm_generic_payload object has no matching delete operation. As I understand your implementation, you want to pool the allocated objects once they've been created for the rest of the simulation to reuse them after they've been handed back to the memory manager for another allocation. Therefore, the right moment to delete your payload objects is when the memory manager is deleted itself. To achieve this, you have to traverse your free_list in the mem_manager::~mem_manager() destructor and call delete on each entry. Additionally, you have changed the visibility of your memory manager destructor from public to private. This is not good object-oriented design. Also, the generic payload pointer *ptr should not be a member variable but rather a local variable to mem_manager::allocate(). Clause 14.5e) of IEEE Std 1666-2011 states that you should also call the reset member function of your tlm_generic_payload object in order to delete any extensions marked for automatic deletion. I hope these hints help you to resolve your memory management issues!
  3. Your problem is not SystemC-specific, as you are not following basic rules of C++ programming: To use classes of SystemC like sc_core::sc_interface or sc_core::sc_module, you have to #include the respective header (in our case <systemc>) before. You haven't done so in your headers comm_interface.h and comm_channel.h Also, your headers comm_interface.h and comm_channel.h seem to lack #include guards, which cause the type redefinition errors. I encourage you to not use the header <systemc> and not <systemc.h> to avoid public namespace pollution. Then, you have to prefix most SystemC classes with the sc_core:: namespace prefix. In function scope, you can avoid this by adding "using" declarations for the symbols/namespaces you plan to use in the current scope.
  4. Hello, The warnings, which you observe are due that the SystemC 2.3.1 sources as the underlying IEEE Std 1666-2011 is still based on the C++'03 standard, but your C++-compiler (g++ 6) defaults to the C++'14 standard. To diagnose the failing tests, you should examine the run.log and diff.log files, which have been generated by the test.sh scripts in the directories with the failing tests. Please report your findings here so that we can see whether there are new issues, which need fixing in a future version of SystemC. To more thoroughly test your compiled SystemC library, you can compile the SystemC regression test suite against your installed SystemC library. Best regards, Torsten Maehne
  5. Dear Joshua, Thank you for your bug report! I have forwarded the issue to the internal issue tracker of the SystemC Language Working Group so that it can be examined and fixed in a future version of the regression test suite. Regarding your port to AArch64, you can post about the necessary modifications in this forum. There is also an upload area accessible via a link on the SystemC Community page of the Accellera website. For possible integration, your modifications have to be licensed under the Apache license. Best regards, Torsten Maehne
  6. Hello Thomas, The voltage drop across an ideal current source is not defined unless there is some load attached to it, e.g., a reasonably sized resistor. The voltage sink primitive you used is also ideal, i.e., its internal resistance is infinite so that it does not fix the voltage across the current source. By the way, for voltage sources, it is similar. They only fix the voltage drop across them, but the current through them is fixed by the attached load. Best regards, Torsten Maehne
  7. Have a look at clause 4.5.7 "Functions to detect pending activity" in the IEEE Std 1666-2011 SystemC LRM. The functions described in this clause should allow you to implement the functionality you are looking for.
  8. Hello Sumit, my advice would be to not mark member functions as noexcept that contain calls to SystemC functions or a library that does throw. Otherwise, any uncaught exception leaving the context of the function noexcept-declared will yield a call to std::terminate(). Yes, annotating functions with noexcept may enable the compiler to do additional optimization. However, many modern compilers already generate code, which doesn't has a performance penalty in the path where no exception occurs. In case an exception occurs, you won't care about the performance penalty caused by the occuring stack unwinding. However, you do usually care about being able to deal with exceptions in places, where you have enough knowledge to properly deal with problem. This is not necessarily in the function you declared noexcept. So, in many cases you probably won't gain much by declaring your member functions noexcept. Still, there are certain places, where declaring functions as noexcept promises more advantages: in particular, move operations, swap, memory deallocation functions, and destructors. This is explained in much more detail in Item 14 of Scott Meyer's book "Effective Modern C++". The SystemC standard still is based on C++'03 and so is the proof-of-concept implementation provided by Accellera. It will require considerable work to move SystemC to actively use C++'11/14/17 features. The topic is on the agenda of the Language Working Group, as the discussion regarding this topic showed during the SystemC Evolution Day in Munich in May. Contributions through participation in the respective working groups are certainly welcome. Finally, to give you some more solid information regarding best practices for using noexcept, I would like to point you to: Scott Meyers "Effective Modern C++", Item 14 "Declare functions noexcept if they won't emit exceptions.", O'Reilly, 2015. Bjarne Stroustrup: "C++'11 FAQ: noexcept -- preventing exception propagation", 2015. Andrzej Krzemieński: "noexcept — what for?", Andrzej's C++ blog, 2014-04-24. Andrzej Krzemieński: "Using noexcept", Andrzej's C++ blog, 2011-06-10. Best regards, Torsten Maehne
  9. Hello Thomas, If this snippet corresponds to your minimal example, then you are accessing the elements on the wrong object. Your variable "grid1" is of type sc_core::sc_module. It contains a private member variable "element", which is your two-dimensional vector array of type sc_core::sc_vector<sc_core::sc_vector<sca_element_model> >. If you want to access the vector from outside the grid1 module, you have to declare the member variable as public. Then, you should be able to call the functions on the individual elements using: grid1.element[j][i].foo() I hope this fixes your error. As a side note: The SystemC AMS extensions LRM reserves all identifiers with prefix sca_ and SCA_ for itself. You should therefore avoid using the sca_ prefix for your own class, function, variable, and preprocessor macro definitions even if you put them into an own namespace. Simply, choose a different prefix instead, e.g.: sca_element_model -> my_element_model Regards, Torsten Maehne
  10. Hello Jean-Claude, Maybe you could try to regenerate the configure script from inside your Cygwin shell. Cygwin tries its best to make Windows look like Unix, but sometimes it cannot hide all differences. Then, Unix programs require patches to work properly. This might be the case for GNU libtool, GNU automake, and GNU autoconf. Install all three packages through the Cygwin package manager and then go to your SystemC root directory. There execute the bootstrap script, which calls libtool, automake, and autoconf in the right order to regenerate configure: .../systemc-2.3.1/> config/bootstrap I hope this helps. It's been a while that I used Cygwin to compile SystemC... Nowadays, I prefer MSYS2 with the MinGW-w64 toolchains. Regards, Torsten Maehne
  11. Hello, the error message about multiple drivers stems from the usage of sc_inout ports in your pipelined bus module. All inout ports bound to a signal act as a potential driver. You can modify the writer policy governing the check for multiple drivers by appropriately setting the SC_DEFAULT_WRITER_POLICY preprocessor definition to SC_ONE_WRITER (default), SC_MANY_WRITERS, or SC_UNCHECKED_WRITERS consistently in all the translation units of your application. Details for this preprocessor definition can be found in the INSTALL file of the Accellera SystemC 2.3.1 proof-of-concept implementation distribution archive. Regards, Torsten Maehne
  12. Hello, As far as I understand your design from your description, you don't need to use a multiport at all to achieve the wanted effect of distributing your power on signal to all modules of your system. A single sc_core::sc_signal<bool> sig_power_on can be bound to one output port of type sc_core::sc_out<bool> and as many input ports of type sc_core::sc_in<bool> as you like. Once a new value is written to the out port, this will trigger an event to which the processes reading from the in port in your modules can be made sensitive. Best regards, Torsten Maehne
  13. Hello, the error lies probably in the order you pass the libraries systemc and scv to the compiler/linker. Instead of specifying first "-lsystemc" and then "-lscv": g++ -L"C:/systemc-2.3.1/lib-cygwin" -o "proba.exe" ./apb_transaction.o -lsystemc -lscv you should specify first "-lscv" and then "-lsystemc": g++ -L"C:/systemc-2.3.1/lib-cygwin" -o "proba.exe" ./apb_transaction.o -lsystemc -lscv The reason is that the SCV library references functions and datatypes of the SystemC library. Therefore, the linker has to resolve symbols of the SCV library and then resolve the remaining symbols to the SystemC library, which stem from your program and the SCV library. Best regards, Torsten Mähne
  14. It would be helpful if you could post a minimal self-contained example demonstrating your issue.
  15. Dear Roman, contrary to the previous poster, I would like to encourage you to keep posting your proposals for improving the syntax of SystemC! They come very timely. The IEEE Std 1666-2011 will need to get revised in the coming years to not become obsolete. The current standard is still based on C++'03 and the next version will need to get aligned to C++'14 or the then current C++ standard version. This forum is the right place for regular SystemC users to expose their ideas about what they would like to see in a revised standards. Members of the SystemC Language Working Group are reading and contributing to the Accellera Forums on a regular basis and are thus aware of your proposals -- even if they don't provide feedback for the moment. Personally, I think that your proposals are a good starting point for thinking further how SystermC users can tear most benefits from the possibilities of the new C++ standards to simplify the code of their models. Improvements to the SystemC syntax, which don't jeopardize backwards compatibility, will be more easy to integrate than proposals, which are not compatible to the current standard. The latter probably need to be very convincing in terms of usability and productivity improvement to get considered in a new revision of SystemC. Personally, I would also try to avoid as much as possible the introduction of any new preprocessor macros in SystemC. So, please keep posting! I hope that also other Forum members will provide feedback in the future. Best regards, Torsten Maehne