Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by maehne

  1. Just for the record: CPPFLAGS is not meant to pass options to the C or C++ compiler when using make , it is used to pass options to the C preprocessor (usually called cpp ). You should use CFLAGS and CXXFLAGS to pass options to the C compiler or C++ compiler, respectively. As Philipp mentioned, using -fpermissive is not a good idea. Regards, Torsten Maehne
  2. I agree with Alain, You should opt for dynamic allocation of your memory -- in this case for your array of ports. By using a container such as sc_vector from SystemC 2.3 or boost::ptr_vector from Boost, the deallocation of the dynamic memory will be automatically handled upon the destruction of the surrounding module or, in general, when the current context is exited. The dynamic allocation of the ports has the additional advantage that you can explicitly call each individual constructor with the necessary arguments to achieve the correct naming of the ports in your design hierarchy. If these containers do not fit your needs using the smart pointers (e.g., shared_ptr<T> , weak_ptr<T> , unique_ptr<T> ) provided by C++ 11, C++ TR1 or Boost may be an alternative. They make handling of dynamic memory much safer, as they also handle the automatic deletion upon context exit or when no one is anymore referencing memory. Best regards, Torsten Maehne
  3. Hello, it's hard to tell where's your problem. Your description of the circuit itself is not very clear. The "attached plot" mentioned in the post is missing. Post a minimal and self-contained code example so that we can see what you've done. In general, the ELN MoC gives correct results for linear electrical circuits. Therefore, I suspect your netlist might not be correct. That said, I would like to insist on the fact that for pure circuit-level modeling a language such as SPICE, VHDL-AMS, or Verilog-AMS might be more suitable. The power of SystemC AMS lies on higher system-level modeling done using primarily the TDF model of computation in conjunction with regular SystemC discrete event and TLM modeling techniques. Best regards, Torsten Maehne
  4. Hello, Are you sure that at this point in your code in reg_interceptor_wrapper.h the <systemc.h> header is already included? sc_bind should be found always, as it is defined in the standard to be a #define to boost::bind, which as a side note is not very proper. So it should be found once <systemc> or <systemc.h> is included in the header. However, sc_spawn() is a function, which is defined in the namespace sc_core. In your error message, sc_spawn isn't prefixed with sc_core::. In that case there should be somewhere a using namespace sc_core; or using sc_core::sc_spawn; somewhere in the header to make it work or <systemc.h> has to be included. All three solutions are not very proper, as you should not use using statements in headers to avoid public namespace pollution. Therefore, als #include <systemc> is preferrerd over #include <systemc.h>. No further diagnosis of your problem is possible without any further context. Best regards, Torsten
  5. Hello Jens, I cannot provide you with links to working memristor model for SystemC-AMS. However, a quick search on Google returns relevant material, which may serve as a starting point: http://www.cnr.berkeley.edu/~goster/pdfs/Memristor.pdf http://www.cpmt.org/scv/meetings/chua.pdf http://krex.k-state.edu/dspace/bitstream/handle/2097/4605/KetakiKerur2010.pdf Personally, I like the bond graph formulation (cf. to Karnopp, Margolis, Rosenberg: "System Dynamics") of the memristor model, as it allows for a straightforward transformation of your model into an equivalent block diagram model, which can be expressed using TDF, by means of causality analysis. For the implementation, my hints from my previous post apply. Regards, Torsten
  6. Hello, please follow Alan's and David's advice. I would like to add that it is good practice to set the port name to be equal to the name of the port instance variable in your module. This can be easily achieved by passing it in form of a string to the port's instance constructor in the member initialization list of the module's constructor, e.g.: SC_MODULE(my_module) { sc_core::sc_in<double> in1, in2; sc_core::sc_out<int> out; SC_CTOR(my_module) : in1("in1"), in2("in2"), out("out") {} // ... }; Once you do it systematically, the SystemC error messages during elaboration and simulation will become much clearer, as they will use real variable names, which you can easily locate in your source code. Regards, Torsten
  7. Hello Sumit, If I understand this forum correctly, then Newbie is a reputation automatically determined by: the number of posts the number of likes you receive by others on your posts, and maybe the number of friends you have on the forum. So it may make sense to take the time to "like" the posts you find valuable. Best regards, Torsten
  8. Hello Jens, regarding the late reply due to lack of notification: This is a weakness of the new forum. You have to configure e-mail notifications manually by clicking on your account name on the top right of the web page and then clicking on My Settings. There you can configure to receive e-mail notifications for followed forums and threads. Afterwards, you still have to select the forums and threads to follow. Regarding your actual modeling problem. If you want to model a memristor in SystemC-AMS, then I agree that a TDF-only solution would be preferable. However, then you'll have to make a choice upon model creation on which causality you assume for the Memristor, i.e. how it is operated. Is it driven by a current or a voltage? This will fix its state and output variable. Then, you'll be able to express you memristor equations in a compact TDF model using e.g. an embedded LTF function for the integration of the current and implementing the non-linear M(q(t)) function inside the processing() member function. An implementation combining ELN and TDF will be suboptimal, as it will imply a tight feedback loop between a controlled resistor and a TDF module implementing the non-linear part of the Memristor equations, which has to be broken with a 1 timestep delay. This causes of course a change in the dynamic of your system and in consequence your simulation results will heavily depend on the chosen TDF timestep. Sumit's remarks on SystemC-AMS not being the most suited modeling language for describing circuit-level behavior are valid. LSF and ELN are limited to describing linear (switched) dynamic behavior and trying to model nonlinear behavior with them by combining them with tightly coupled TDF modules leads to suboptimal results. It's a simulation framework intented for the system-level, where most of the circuit level details have been abstracted away to focus on the system architecture and evaluate specifications for whole signal processing and control chains, which contain a significant amount of digital Hw/Sw. In contrast to VHDL-AMS and Verilog-AMS, SystemC-AMS does not offer a nonlinear network MoC, which allows you to solve nonlinear DAEs. Though, Fraunhofer IIS/EAS in Dresden have developed one, which integrates seamlessly into SystemC-AMS, you can check out the publication of Thomas Uhle in SOCC 2010 on it. However, it is not available as open-source. Therefore, VHDL-AMS or Verilog-AMS may still be a more appropriate choice for your needs. Best regards, Torsten
  9. Hello Gurunath, your code is still buggy for both cdma_data and CDMAVec. Both functions, sc_trace() as well as operator<<() have to be declared as free functions and not as member functions of the respective data structures! You have to move them out of the struct/class definition. Inside the class definition of CDMAVec, only a friend declaration (without function body) needs to remain so that the implementations of sc_trace() and operator<< can access the private members. You should reconsider your choice of inheriting protected from std::vector<T>. Is your CDMAVec to be considered as a specialization of std::vector<T> or not? If yes, the inherit public from this type. If not, then inherit private from this type. If you look into Scott Meyer's Effective C++/STL book series, you'll find some guidance to answer this question (sorry for being vague, but I don't have copies of the books at hand). There may be good reason to choose composition instead of inheritance, i.e. to have a private std::vector member instead of inheriting from it. This allows you to better decouple your interface from the interface fixed by std::vector. You should also consider to check out the C++ FAQ lite on http://www.parashift.com/c++-faq/ which also discusses these issues and how to correctly overload operators.
  10. Indeed, SystemC 2.1 has similar issues, but you may be lucky that it'll require less work than SystemC 2.0.1.
  11. This is a very old version of SystemC. You should use at least SystemC 2.0.1, which fixes some bugs. As Philipp noted, this version is not compatible with modern C++ compilers so that it requires quite some fixes until it will compile without errors and warnings. This will require quite some effort from your side to Google for the warnings and resolve them in the source files. As noted by Philipp, SystemC 2.0 is not compatible with the x86_64 architecture, so you'll have to compile it and all dependent libraries (i.e. in your case Metropolis) for the i386 platform. You can force it during the configure step: $ cd systemc-2.0.1 $ mkdir objdir $ ../configure --target=i396-unknown-linux-gnu $ make However, for the QuickThreads part to compile, you'll have to play additionally with the compiler flags, as Philipp mentioned. To this end, you'll have to edit the Linux section of configure.in to add -m32 to EXTRA_CXXFLAGS and add ASFLAGS="--32". It should look like: *linux*) case "$CXX_COMP" in c++ | g++) EXTRA_CXXFLAGS="-Wall -m32" ASFLAGS="--32" DEBUG_CXXFLAGS="-g" OPT_CXXFLAGS="-O3" TARGET_ARCH="linux" CC="$CXX" CFLAGS="$EXTRA_CXXFLAGS $OPT_CXXFLAGS" ;; *) AC_MSG_ERROR("sorry...compiler not supported") ;; esac QT_ARCH="iX86" ;; Replace <ieeefp.h> by <cmath>. You'll also stumble about other deprecated headers, which will be included. Also the Endian detection in "scfx_ieee.h" fails, you'll have to #define SCFX_LITTLE_ENDIAN to work around this issue. At this point compilation will still fail at various places in the kernel (sc_thread_cor_fn, sc_cthread_cor_fn) and the integer and fixed point libraries (for the different overloaded operators). Primarily, this is due to missing declarations of functions or classes, which are referenced in the implementation and have been previously only introduced in form of friend declarations, but not as proper declarations. You'll have to add those declarations in the appropriate places, preferably in the corresponding header in front of the class with the friend declarations. I gave up at that point. Good luck in trying to make SystemC 2.0 build again. It may be more productive trying to make Metropolis compatible with the current SystemC version. Though, you risk to run in the same issues. Therefore, you may consider to install both into a virtual machine running a 32bit Linux from that time (e.g., Redhat or Debian) Regards, Torsten
  • Create New...