maehne
-
Posts
366 -
Joined
-
Last visited
-
Days Won
43
Content Type
Profiles
Forums
Downloads
Events
Posts posted by maehne
-
-
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
-
Hello,
Hello people!
I need to model a 2-bit flash adc converter according to the standard SystemC AMS for a university project.
I have already modeled TDF in the generation part of the analog signal by setting the timestep and all other parameters.
Now the samples of the output voltage from the module TDF end to the input of a module ELN which should represent the circuit, made of resistors, comparators and reference voltage that effect the operation of A / D conversion.
I'm having problems:
1) in shaping the comparators (I use what I find in sc_nullor.cpp and if so, how?)
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.
2) for the reference voltage would like to understand what needs to be defined.
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 voltage, the comparator should output '1' and '0' otherwise.
If you have solutions ready for use are welcome!
We won't do your homework.
Thanks in advance!
Regards,
Torsten
-
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 behavior.
Regards,
Torsten Maehne
-
Hello,
I fully agree with your comments above, however may I point out.
1. SPICE model already works, and this is an attempt to create a
high level model.
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.
2. The circuit is very simple, a L and a R in series, with a voltage
controlled voltage source and a current controlled current source
connected in parallel to the L node other than the one connected
to the R. The controlled current source output looks as expected,
but the controlled voltage source output is zero. source The RL is
excited with a square wave pulse train.
Self-contained source code follows shortly
We'll wait for your source code, as a textual description of your circuit is not sufficient to diagnose the source of your problem.
-
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
-
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
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
-
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
-
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
-
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
-
http://www.cnr.berkeley.edu/~goster/pdfs/Memristor.pdf
-
Hello,
please follow Alan's and David's advice.
t1.m1.port_3
tells you exactly which port is not bound. t1 and m1 are names you created. port_3 is the default name for the 4th port you declared in the module that is instanced as m1,
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
-
Hello Sumit,
Further-more it says both myself and Torsten are newbies
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
- the number of posts
-
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
- sumit_tuwien and jb22
-
2
-
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.
-
Indeed, SystemC 2.1 has similar issues, but you may be lucky that it'll require less work than SystemC 2.0.1.
-
Hello,
I'm installing systemc 2.0 on x86 64bit machine, and Ubuntu12.04 OS.
I need this version as a requirement for Metropolis installation (newer versions are implying errors when installing metropolis).
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.
Upon configuration, I got the following error:
checking build system type... Invalid configuration `x86_64-unknown-linux-gnu': machine `x86_64-unknown' not recognized
configure: error: /bin/bash ../config/config.sub x86_64-unknown-linux-gnu failed
I resolved this by replacing the config.sub file with the latest version (downloaded)
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" ;;But when I do make, I get some errors indicating that quickthreads (qt.h) requires preprocessor definitions for the architecture (e.g. stack alignment).
This was resolved by forcing __i386 in EXTRA_CXXFLAGS in the makefile. Is this valid??
Another error says: ieeefp.h is missing (fatal error: ieeefp.h: No such file or directory compilation terminated). How can this be resolved?
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)
Thanks
Regards, Torsten
How to create a tabular trace file in SystemC ?
in SystemC Language
Posted
Hello,
if you can link your model to SystemC-AMS, you may also try to use its tracing facility to which you're already accustomed. SystemC-AMS allows the tracing of pure SystemC signals and ports (cf. LRM clause 6.1.1.9) via sca_util::sca_trace() to tabular trace files opened via sca_util::sca_create_tabular_trace_file(). You may set the sampling time by passing sca_util::sca_sampling(tstep) to member function set_mode() of your pointer to an instance of sca_util::sca_trace_file.
However, I have to admit that I never tested using sca_trace() in an otherwise pure SystemC model. In the worst case, you'll have to create a dummy TDF module to which you assign the sampling time step as module time step.
Regards,
Torsten Maehne