Jump to content

maehne

Members
  • Content Count

    259
  • Joined

  • Last visited

  • Days Won

    31

Everything posted by maehne

  1. Thanks for reporting this issue! I think your use case is justified. However, the decision to not installing the header seems to have been made on purpose as utils/sc_stop_here.h is explicitly added to NO_H_FILES in src/sysc/utils/files.am. The behavioural difference between the Automake and CMake-based build flow is probably unintentional. I have reported the issue to the LWG for investigation.
  2. Building SystemC using G++ from MSYS2/MinGW-64 should work as described in the INSTALL file. To diagnose your problem, it would help if you could provide all commands, which you used to configure and build SystemC 2.3.3 and then to run the tests. Please, also provide the log file generated by configure. Did you observe any errors/warnings during the compilation of the SystemC library? You should pass in the CXXFLAGS to your configure call as described in the INSTALL file, section "SystemC Library Configuration Switches": ../configure CXXFLAGS="-DSC_OVERRIDE_DEFAULT_STACK_SIZE=0x80000" You can also try to build SystemC with the latest fixes released in its official public Git repository. You can also try to build SystemC from that repository using CMake as described in cmake/INSTALL_USING_CMAKE.
  3. Thanks @plafratt for providing these additional details. I have reported this issue to the LWG for investigation. The warning can be probably fixed by default-initialising the tmp in line 235 of sc_fifo.h
  4. Your message is not providing enough information about your environment. Which version of SystemC did you compile. I suggest you to start with the latest released version of the SystemC proof-of-concept library. Did you follow all the instructions found in section "Installation Notes for Windows" of INSTALL.md? Did you compile SystemC as a static library or DLL? Where you able to build and execute the examples coming along with the SystemC library? Did you also follow the instructions for "Creating SystemC Applications" when you compiled your test program? If you want to link your application against a DLL build of SystemC, you also have to following the instructions in the section "Building against a SystemC DLL". Especially, when running the simulation, your SystemC DLL needs to be in the PATH!
  5. Have you tried to compile and run a simple hello-world-style C++ program in the same environment, from which you called configure? The config.log shows that your PATH contains the bin directories of many different EDA toolchains. Some of them come before the bin directories of your host OS. This may cause issues as these EDA toolchain installation tend to include a lot of basic libraries, which are normally provided by the host OS. This can cause interferences. You may try configure and build SystemC in an environment, where the PATH got pruned of all the EDA toolchain bin paths.
  6. @plafratt: It would be very helpful if you could provide more detailed information to reproduce your observation as suggested by @Roman Popov. With what version of g++ running on which platform have you observed the warning. A small self-contained code example demonstrating the issue would help us to reproduce the issue on our side so that we can forward the issue with enough information to the SystemC Language Working Group for fixing.
  7. Thanks @Asdruv for reporting this bug! I have forwarded your report to the LWG. Best regards, Torsten Maehne
  8. sc_core::sc_in<T> only allows binding of a single sc_core::sc_signal<T> (cf. to IEEE Std 1666-2011, clause 6.8). However, you may use for in_B a sc_core::sc_port<sc_core::sc_signal_in_if<T>, 3, SC_ONE_OR_MORE_BOUND> (cf. to IEEE Std 1666-2011, clause 5.12) that will accept binding of exactly three signals. The implementation of the OR relation of the three signals can be then handled inside an SC_METHOD of objB. To access the three different signal from in_B, you can use the operator[] implemented by the sc_port. By the way, you may also specify a different number of channels to be bound and also a different port binding policy.
  9. If you don't use the member functions added that were added for convenience to `sc_in`, `sc_out`, and `sc_inout` to, e.g., call `read()`, `write()`, and the event member functions via the `.` operator than via the corresponding member function in the interface accessed via the `->` operator, you might be able to avoid entirely the derivation of new port classes. Instead, you could simply use a template alias, which was introduced with C++'11: template<typename T> using sc_in_opt = sc_core::sc_port<sc_signal_in_if<T>, 1, SC_ZERO_OR_MORE_BOUND>; template<typename T> using sc_inout_opt = sc_core::sc_port<sc_signal_inout_if<T>, 1, SC_ZERO_OR_MORE_BOUND>; template<typename T> using sc_out_opt = sc_core::sc_port<sc_signal_inout_if<T>, 1, SC_ZERO_OR_MORE_BOUND>; If you want to also provide all member functions of `sc_in`, `sc_out`, and `sc_inout`, you will have to derive from the `sc_port` class and implement the full interface as defined in IEEE Std 1666-2011.
  10. This output does not hint for any problem. What output do you expect from your alu model? You need to implement explicitly any debug output in your SystemC model using, e.g., the SC_REPORT_* macros. Tracing of signal using the sc_trace() mechanism won't cause any additional output on the console either. If you expect some output, you will have to share the code of a minimal working example exposing your problem. Your CMakeLists.txt looks mostly fine. However, it contains several unnecessary lines. After finding SystemC using find_package, you only need to make sure that your executable target is linked against the SystemC::systemc target using the target_link_libraries(alu SystemC::systemc) call. CMake retrieves from this target automatically any necessary compiler flags, preprocessor definitions, include paths, and library paths, which previously needed to be set up by hand. So, your minimal CMake file could look something like: cmake_minimum_required(VERSION 3.1) project(alu) find_package(SystemCLanguage CONFIG REQUIRED) # # Setting the C++ standard from the SystemC_CXX_STANDARD variable may be still # # needed to compile without. So, in case of errors, try to uncomment the # # following two set (...) commands. The experimental CMake-based build system # # of the SystemC PoC implementation needs some updates to simplify further # # building SystemC application using CMake by using features introduced in # # CMake >3.11, which enable specifying even better the build and usage requirements # # of a library or executable. # set (CMAKE_CXX_STANDARD ${SystemC_CXX_STANDARD} CACHE STRING "C++ standard to build all targets. Supported values are 98, 11, and 14.") # set (CMAKE_CXX_STANDARD_REQUIRED ${SystemC_CXX_STANDARD_REQUIRED} CACHE BOOL # "The with CMAKE_CXX_STANDARD selected C++ standard is a requirement.") add_executable(alu main.cpp testbench.cpp) target_link_libraries(alu SystemC::systemc) The Section 4 of cmake/INSTALL_USING_CMAKE file contains some more hints.
  11. Your calls to the configure script don't include the option --prefix to specify the destination directory for installation. This is strongly recommended as the SystemC installation layout does not match well with the standard Unix directory layout for a conflict-free installation. Personally, I prefer to install SystemC on Unix-like platforms to /opt/systemc-2.3.3 (or similar). After make install, you can make sure that the include and lib-* directory below the prefix contains the necessary files. When building against this SystemC version, you will have to pass the proper include and linker flags. I recommend that you read the INSTALL and RELEASENOTES files, which are part of the SystemC PoC implementation. You may also consider to use the experimental CMake-based build system instead of the autotools.
  12. Before implementing your own ports and attempting to modify the SystemC code, you should first get familiar with the basic concepts and capabilities of SystemC. I suggest that you read a good introductory text to SystemC, e.g., "SystemC from the Ground Up" by David Black et al. That said, your requirement description seems to indicate that you could achieve the wanted functionality by using simply the standard SystemC ports and signals: One instance of sc_core::sc_out<T> in some module, which drives the global signal of type sc_core::sc_signal<T> that is bound to it during elaboration. And n port instances of sc_core::sc_in<T> bound to the same signal. You can then make some SC_METHOD or SC_THREAD in the module which instantiates one or several of this in ports to be sensitive to changes on this/these ports.
  13. The SystemC libraries and their associated headers are usually not installed into the standard locations (/usr/lib/ and /usr/include/), where they would be found automatically by the compiler and linker. Instead, they are typically installed into their own directory hierarchy, e.g., below /opt/systemc-2.3.1/. Therefore, you need to indicate their location explicitly to the compiler and linker by passing the appropriate flags, e.g.: $ c++ -o my_tb my_tb.cpp -I/opt/systemc-2.3.1/include -L/opt/systemc-2.3.1/lib-linux -lsystemc Due to this, you also usually include the SystemC header using #include "systemc" to indicate that it is not a standard system header. I suggest that you first test your SystemC installation by compiling, linking, and running a pure SystemC example (e.g., the single-file simple_perf example, which is distributed as part of the SystemC PoC implementation in the directory examples/sysc/simple_perf/). From your questions, it seems that you are not particularly familiar with C++ and the associated toolchains. I would recommend that you first learn about them before focusing on SystemC and then Nigram.
  14. Either you as the library author or the user of that library will need to provide at least an empty implementation of sc_main() to satisfy the linker. There is no way around it. I would like to also suggest that you update your SystemC installation to the latest version 2.3.3.
  15. value_changed_event() returns a constant reference to an sc_core::sc_event. A SystemC method or thread can be made sensitive to that event to get activated each time the corresponding sc_event gets notified. Easiest would be to connect your sc_signals to matching sc_in port of a dedicated module, which sets up the method or thread responsible for counting your bit changes. I recommend that you read a good introduction to the basic concepts of SystemC, e.g., David C. Black et al. "SystemC from the Ground Up", 2nd ed. The SystemC elaboration and simulation semantics are also described in clause 4 of the freely available IEEE Std 1666-2011. If you are not yet much familiar with C++ itself, it might be a good idea to get first familiar with the fundamental concepts of C++ first.
  16. The implementation of the TLM proof-of-concept library depends on SystemC. Therefore, you will need to link your application, which makes use of TLM, to the SystemC library. You can check it yourself by looking into the corresponding TLM headers: They include headers that are part of the SystemC implementation. Furthermore, the TLM implementation is not anymore header-only. The compiled .cpp implementation files are directly linked into the SystemC library file.
  17. Thanks for reporting this bug! I forwarded it to the SystemC Language Working Group, so that it can be fixed for the next release of the SystemC proof-of-concept library.
  18. Glad I could help! You have grasped the idea correctly.
  19. To achieve activation of your TDF controller only once per 5 activations of the valve and water tank modules, you will need to assign in addition to the time step also consistent rates to the TDF ports. E.g., you could assign to the TDF controller outputs command and threshold a rate of 5. Then, the connected valve and water tank modules will be activated 5 times per activation of the controller. As then the water tank will also output 5 times a water level sample to be read by the controller module, you will also need to assign a rate of 5 to the controller's input port. At this point, the TDF cluster is still not schedulable, as you have a feedback loop, which requires the insertion of a proper number of delay samples to achieve causality. To this end, you could, e.g., assign a delay of 5 to the controller input. For better understanding of the basic concepts of TDF modeling, I strongly suggest that you read at least the section 2.1 "Modeling fundamentals" of the SystemC AMS User's Guide available from the Accellera website.
  20. @Martin Barnasconi is of course right about that there is no SCA_ELN_MODULE macro defined in the SystemC AMS standard, as it is currently not possible to define own primitive ELN modules. Personally, I prefer to avoid the use of preprocessor macros in C++ as much as possible -- especially when a fully equivalent concise proper C++ syntax exist. In the context of SystemC (AMS) the macros SC_MODULE, SCA_TDF_MODULE, SC_CTOR, and SCA_CTOR obfuscate in my humple opinion more the code than they help to render SystemC models more readable. Your class LifELN is very probably a class derived from sc_core::sc_module (SC_MODULE) and which contains the netlist of your ELN model (i.e., a circuit of ELN primitives). The time step needs to be set always on at least one instance of a primitive SystemC AMS module, which is part of a cluster of connected SystemC AMS primitive modules. Therefore, your second approach: is the correct one.
  21. I have forwarded your issue to @karsten from COSEDA Technologies, as he is the principal author of the SystemC AMS PoC implementation.
  22. Thanks for reporting these compilation issues! These will need to get addressed by the COSEDA Technologies GmbH with a new SystemC AMS release. In the meantime, you can fix the compilation issue by replacing: pobj->sca_name() with this->name() The calls to memcpy() and memset() need to get prefixed with the std:: namespace prefix. The "register" storage class specifiers can be safely removed. If I see it correctly, they are only remaining in file scams/impl/analysis/ac/sca_ac_domain_entity.cpp.
  23. You seem to use the right approach of using an SC_MODULE to describe the structure of your circuit of ELN primitives. The macros SCA_ELN_MODULE and SCA_TDF_MODULE are exclusively used to define primitive modules in the respective MoCs, which describe the behaviour of the primitive, but not their inner structure. The statement from the SystemC AMS LRM regarding setting the time step refers to the set_timestep() member function, which is offered by all SystemC AMS primitive modules. To keep my models flexible, I tend to prefer to set the time step from the test bench or top level module by calling the set_timestep() member function of one of the accessible primitive AMS modules in that scope, i.e., usually a stimuli source. E.g., if you have instantiated a sca_eln:sca_vsource src1("src1", 2.0); you would call src1.set_timestep(10.0, sc_core::SC_US); to set the time step of the module src1 and the connected ELN cluster to 10 us. I hope that this answers your primary question. I definitely recommend you to read the SystemC AMS User's Guide to get a better insight into the fundamental concepts of SystemC AMS. It is an unfortunate situation that it is currently so hard to find as it is only provided as a bundled download together with the outdated Accellera SystemC AMS 1.0 standard. You can download it from the Accellera's SystemC standards page, where it is listed as "AMS 1.0" in the "Previous releases" section. The statements from this User's Guide are still relevant. It only lacks discussion of the advanced Dynamic TDF modelling features, which were added in SystemC AMS 2.0 and are also part of IEEE Std 1666.1-2016. Unfortunately, efforts to update the user's guide to the current SystemC AMS standard version got stalled due to lack of time of the involved people in the working group.
  24. Thanks for the clarification and feedback on the fix suggested by Philipp!
×
×
  • Create New...