Jump to content

karsten

Members
  • Content Count

    24
  • Joined

  • Last visited

  • Days Won

    4

karsten last won the day on January 16 2017

karsten had the most liked content!

About karsten

  • Rank
    Member

Recent Profile Visitors

702 profile views
  1. I just saw, that it looks like you instantiate the modules statically. You may run into the OS stack size limitation. Allocate the modules/vectors dynamically (using new) may solves the problem (or at least increases the possible size). May you can try similiar like this (not checked): sc_vector< sca_eln::sca_node >* c_vec; //nodes beteen resistors sc_vector<sca_eln::sca_r>* rs_vec; SC_CTOR(rmatnn): p("p"),n("n") // { c_vec=new sc_vector< sca_eln::sca_node >("c_vec",
  2. There is no real limitation except the available memory. Each resistor is a SystemC module which allocates some memory due the sc_module members. I guess SystemC and SystemC AMS does not check always, that memory could be allocated - thus you get the segfault. You can try a computer with more memory or try to setup the equation manually- for a resistive network this should be some lines of c code only - if you have inductors or capacitors you can use the state space or Ltf objects.
  3. Due SystemC AMS is a C++ library on top of SystemC only, all simulators, which support SystemC principially also support SystemC AMS. We tested this for different Cadence, Synopsys and Mentor versions.
  4. RNM uses the digital event driven model of computation (MoC) to allow abstract analog signalflow based behaviour. For such an purpose event driven simulation is not optimal - the dataflow MoC available additional in SystemC AMS is therefore more efficient and introduces less artefacts like unneccesarry activations. Additional, modelling of dynamic behavior (transfer function, filter, ...) with RNM is difficult. You can transform your equations into a digital filter (e.g. using bi-linear transformation) or you have to use Verilog-A(MS) and thus the analog simulator which will slow down the
  5. Thats consistent - you have around 16.000 modules - and I assume they are connected in a kind of chain, which is the worst case for the algorithm. So the required maximum depth should be less than 16.000 may less. Best regards Karsten
  6. The issue is not the SystemC stack size (the size which can be used by SystemC threads). The current SystemC AMS proof-of-concept uses a recursive algorithm for clustering. So in the worst case the recursive-depth during elaboration equals to the number of connected modules. So far, I know, the maximum stacksize is a parameter of the operating system, which can may be increased. I have no expierence with this, may you can try the following links. I'll be interested in the result. http://stackoverflow.com/questions/7535994/how-do-i-find-the-maximum-stack-size http://stackoverflo
×
×
  • Create New...