Jump to content

maehne

Members
  • Content Count

    315
  • Joined

  • Last visited

  • Days Won

    37

Everything posted by maehne

  1. Hello, To sense the voltage at an ELN node, you can use and sca_eln::sca_tdf::sca_vsink. Its p terminal, you would connect to the node in question and its n terminal to ground. The voltage becomes then available at its outp port, which can be connected to a TDF signal. The latter you can then connect to your TDF comparator. Regards, Torsten
  2. Hello, You cannot directly model the comparator as an ELN module, as this constitutes a nonlinear behavior. The nullor is represents and ideal op-amp with infinite gain and no output limitation. I suggest to use a sca_vsink and a TDF module to implement the comparator. You've to implement the resistor-ladder, which is to be polarized by VDD and VSS at its both ends. Thus, the reference voltages will be available at the nodes between the resistors. The vsink of the comparator will then sense the voltage between the voltage at the ADC input and the reference node. In case of positive volta
  3. Hello, thanks for sending the source code. Without running your model, I can see from it that SystemC-AMS is right, when it calculates vout to always zero. The reason is that your vcvs0 input is connected in parallel to the cccs0 input, i.e., from n3 to gnd. As the cccs0 input shortcuts n3 to ground, the voltage drop is always zero. I guess you meant to measure the voltage across the inductor, from n2 to gnd or n2 to n3. By the way, you don't need to decouple the voltage and current sinks from the electrical circuit. They're considered as ideal and therefore won't influence your circuit beha
  4. I agree, if this model is meant as an intermediary step. Just changing the modeling language doesn't give you a higher-level model. You'll also need to simplify your model to raise the actual level of abstraction sacrificing precision for speed. We'll wait for your source code, as a textual description of your circuit is not sufficient to diagnose the source of your problem.
  5. 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
  6. 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.
  7. 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 d
  8. 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;
  9. 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
  10. 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 elab
  11. 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
  12. 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
  13. 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 c
  14. Indeed, SystemC 2.1 has similar issues, but you may be lucky that it'll require less work than SystemC 2.0.1.
  15. 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 t
×
×
  • Create New...