Jump to content

maehne

Members
  • Content count

    155
  • Joined

  • Last visited

  • Days Won

    18

maehne last won the day on December 12

maehne had the most liked content!

1 Follower

About maehne

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male
  • Location
    Burgdorf, Switzerland

Recent Profile Visitors

762 profile views
  1. Instead of #include <string.h>, you should better #include <cstring> and then add std:: prefixes to the string function calls, which are not found. This avoids polluting your public namespace with identifiers from string.h.
  2. Initialization of nested sc_vector< sc_vector< > >

    Philipp in his post from 2017-09-22 already provided you with the answer: To create your two-dimensional array of modules, you actually need two element creators: One for the outer vector, which will create entire rows of modules: This is the one you have implemented with you module_model::element_vector_creator(size_t size, const char* name, size_t) member function. Another one for the inner vector, where you will allocate the individual modules. This is what Philipp demonstrated with his element_creator Lambda function. He just allocated the module and passed the module's base name as an argument. However, you can also pass any additional arguments to the constructor of the module, e.g., your argument r_value. The arguments, you pass to the constructor can be either hard-coded or calculated based on the current index for the element to initialise (i.e., the second argument passed to the element_creator, which is of type std::size_t). If you also need the current index of the outer vector, you can capture the variable representing that outer index for use within the lambda (check a book on Modern C++ discussing Lambdas for details). You can find more information on sc_vector in clause 8.5 of IEEE Std 1666-2011. However, more accessible might be the paper "Automated SystemC Model Instantiation with modern C++ Features and sc_vector" by Ralph Goergen, Philipp Hartmann, and Wolfgang Nebel from DVCon-Europe 2015: and the "An Introduction to IEEE 1666-2011, the New SystemC Standard" video tutorial by John Ainsley, David C. Black, and Tor Jeremiassen: http://videos.accellera.org/ieee16662011/index.html
  3. makefile SystemC

    Your stimuli_pressure_mech_process() member function has to be registered as a SC_THREAD and not a SC_METHOD to be able to use the wait() functions for timing the application of your stimuli. It is not good practice to use the <systemc.h> header. Instead, you should get used right from the start to use the <systemc> header and prefix SystemC functions and types with the appropriate namespace prefixes. In context of functions, you can abbreviate typing by using "using" statements (e.g., "using namespace sc_core;") (cf. to a good book on C++). Also, instead of deactivating the deprecation warnings, you should fix the source of the problem in your code. "sc_start(200)" with only the integer argument is non-standard and, if I remember correctly, has been removed from recent versions of the SystemC PoC simulator. Instead, you should also specify the time unit, e.g., "sc_start(200.0, sc_core::SC_NS);". I suggest you read a good introductory book on SystemC, e.g., "SystemC from the Ground Up".
  4. Regarding your port binding error: It is not sufficient to bind the isink.n terminal to another terminal. Instead, you have to make sure that through these terminal-to-terminal bindings at some point a node of type sca_eln::sca_node or sca_eln::sca_node_ref is bound. (This is basically the same as SystemC allows port-to-port bindings, but requires any port to be bound at some point to a channel.) Regarding setting the sample time of the ELN/TDF cluster: You can use the sca_core::sca_module::set_timestep() member function for this purpose, which can be used across all MoCs (TDF, ELN, LSF) as their specialised primitive module classes derive from the sca_core::sca_module base class.
  5. Elaboration time sized array

    Hello Roman, instead of developing your own class, have you considered to use std::unique_ptr<T[]> (C++'11) and std::make_unique<T[]> to allocate your array of a fixed size during elaboration? For examples see, e.g.: http://en.cppreference.com/w/cpp/memory/unique_ptr http://en.cppreference.com/w/cpp/memory/unique_ptr/make_unique Regards, Torsten
  6. installing systemc-ams

    The SystemC AMS proof-of-concept library is available for download from the COSEDA Technologies GmbH: http://www.coseda-tech.com/systemc-ams-proof-of-concept The archive contains an INSTALL file with detailed instructions for building SystemC AMS with MS Visual Studio.
  7. This error message suggests that SystemC itself was not built with the C++'11 standard enabled. Please follow the INSTALL instructions in the SystemC 2.3.2 PoC distribution archive (Section "Preprocessor switches" SC_CPLUSPLUS). The C++ language standard needs to be consistently defined for the SystemC library and your application. This is enforced by the sc_api_version_* linker symbol that you see in the error message.
  8. You don't have to create a new ELN primitive to achieve what you described. However, the sketched-out approach is good: Indeed, you have to connect a sca_eln::sca_vsink and sca_eln::sca_isink to your ELN circuit for which you want to trace the power to measure the voltage drop across and the current flowing through the circuit. Describing such an ELN netlist is done in an sc_core::sc_module instead of an sca_eln::sca_module as a netlist constitutes a structural description of the circuit and not a new ELN primitive (which would add new equations describing the circuit element behaviour to the equation system). Defining such user-defined ELN primitives is not standardised in IEEE Std 1666.1-2016 so you have to live with the pre-defined set of ELN primitives. The isink and vsink modules have a TDF output port, which you have to connect via two signals to a user-defined TDF module, which will define in its processing() member function the calculation of the power and the updating of the corresponding trace variable. Depending on your needs, you may also consider to add a second trace variable for tracing the energy (i.e., the integral over time of the power). You might consider to wrap the isink and vsink as well as the power-calculation TDF module into an sc_core::sc_module, which only exposes the electrical terminals needed for power measurement and the trace variables. This may simplify instantiation of several power measurements. Another approach you may consider is to simply trace the relevant voltages and currents and calculate the power/energy offline in your waveform viewer or math tool, which can process the SystemC AMS trace file format (e.g., Octave).
  9. The memory leaks reported by valgrind, which are related to quickthreads are likely false positives, as is explained by Philipp A. Hartmann in this older thread "SystemC 2.3: valgrind error". Regards, Torsten
  10. Sorry for the late reply! I just saw that this post now. The lines containing scv_report_handler::set_actions(...) in the _scv_message::setup() member function implemented in scv_report.cpp were removed by @StS as suggested in my post from 2017-08-08. So you just stumbled again over the same issue.
  11. Because this detects early common errors when describing the behavior of digital circuits, which would be fatal if they get implemented through logic synthesis. If two gates (represented by different processes, i.e., SC_THREAD or SC_METHOD) drive the same signal line, the resulting behavior in hardware is hard to predict and depends heavily from the used technology. Correct logic levels on the signal line are not anymore guaranteed and high currents flowing constantly through the same wires from VDD to GND can damage the IC. If different gates shall drive the same line (common to model signal busses), they need to have tristate outputs and the logic has to guarantee that driving the line is mutually exclusive. If we come to writing test benches, activating SC_MANY_WRITERS in certain selected cases may be necessary to, e.g., easily inject faults inside the DUT. So, IMHO, the default of SystemC is sane and protects the user.
  12. I agree with Roman that UVM-SystemC is the way to go in the long run. In the meantime, you should be able to avoid the observed warnings by passing globally unique module names to the modules and sc_objects you are creating across all tests. This should satisfy the hierarchical name registry of SystemC. To my knowledge, the latter does not keep track of deallocation of sc_objects and thus that its corresponding hierarchical name is not anymore used. Be aware though that you may run into other surprises as the SystemC kernel is currently not able to fully restart from scratch elaboration and simulation.
  13. A strange SystemC warning

    The root for your problem is not in the implementation of SystemC, but in your code. You forgot that in C, you cannot simply concatenate C string (i.e., arrays of type char) by adding them. Instead of concatenating strings the addition of char(ID+'A') to the string "My_Name_" modified the pointer to the string to point ID+65 positions beyond the start of the original string. At that point in memory is probably only garbage, which was interpreted by the sc_object constructor as an object name thus causing the illegal characters warning. To properly concatenate strings in C, you need to reserve a big enough buffer to hold the concatenated result and then use strcpy(), strcat(), strncpy(), strncat() functions copying / concatenating strings. However, in C++, you can use std::string to simplify your task. The following code should work. Though, it may not be optimal in terms of performance (a std:: string gets temporarily constructed): scMod((std::string("My_Name_") + char(ID+'A')).c_str())
  14. SystemC/TLM Debian packages

    Since the relicensing of the SystemC reference installation under the Apache 2.0 license, there should be no more legal obstacles for package the SystemC libraries for your favorite Linux distribution. Someone just needs to make the effort. Both, the new experimental CMake-based build system introduced with the SystemC 2.3.2 public preview release as well as the autotools based build system provide the necessary functionality to configure/compile/install SystemC in an unattended way, which is needed to automatically build the usual package formats DEB and RPM. CMake comes even with CPack, which should further simplify the process. However, the current CMakeLists.txt files in the SystemC 2.3.2 public preview release do not yet contain the necessary settings for CPack due to the limited bandwidth/time of the authors. Feedback and suggestions on how to improve the installation of the SystemC libraries as well as actively contributing to their development by becoming a member of the respective Accellera working groups are welcome!
  15. Dear Frank, Thanks for reporting this issue! I have reported your issue to the SystemC Verification Working Group. I agree with you that scv_message should not tamper with the default actions for error/fatal messages. I checked the SCV code base by following your track. The actual setting of the default actions happens at the first call to _scv_message::setup() in src/scv/scv_report.cpp lines 96 and 97. By removing these two lines and recompiling/reinstalling SCV, you should be able to fix this issue. Best regards, Torsten Maehne
×