Jump to content

Philipp A Hartmann

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Philipp A Hartmann

  1. This is very hard to tell, without any details about your model or the individual components. Options include Use less memory in your model (and look for memory leaks). Buy more physical memory from your favourite hardware shop. Switch to a 64-bit simulation (assuming you have enough physical memory), since 32-bit processes are usually limited to a 2GB address space. Do you allocate (very) large memories (i.e. arrays) in your model?
  2. You run out of memory and a "new" expression throws an exception.
  3. You can either ignore the warning, or increase the maximum known version to 1700 (= Visual C++ 2012) in src/sysc/packages/boost/config/compiler/visualc.hpp:162. /Philipp
  4. There is no fixed limit on the size of sc_vector instances, as they are using a std::vector of pointers internally, which has now hard-coded limit either. Apart from the size of the FRAME module itself (in terms of members, etc), you need to consider the required stack allocations for any SC_THREAD processes in the modules as well. If you really need such high numbers of modules, you should try to use SC_METHOD processes whenever possible. Another option may be to reduce the allocated stack size via the set_stack_size() function. Greetings from Oldenburg, Philipp
  5. You're including internal system headers twice, and those are (deliberately) not protected against that. Moreover, the inclusions differ in the platform selection (amd64 vs x86). So, your installation and/or platform configuration is almost certainly messed up. On a closer look at the command-line you posted, I noticed that you include pre-compiled headers for 64-bit and 32-bit: This may be related to your problems. You should try to compile your model without using the pre-compiled headers (...systemc/include) first. You also need to check, if the define LNX86 is correct/sufficient for building on a 64-bit system. After all, if you want to avoid such problems, you may need to use a vendor-supported OS as Alan pointed out. Greetings from Oldenburg, Philipp
  6. Your solution looks correct. You may want to consider wrapping all of this together in a single "thread-safe input queue" for better encapsulation (and to remove the pthread stuff from your SystemC model). In this case, you can duplicate the queues internally: At protected one for pushing from the outside and a SystemC-local one, where to store the tokens that you need to process within the SystemC part of the model. With a swap of these queues in the update step, you can keep the locking times minimal. Secondly, if you accept a slight extension beyond the plain 1666-2011 standard, you can use sc_scoped_lock and sc_host_mutex instead of the plain pthread_mutex_* API (untested): template< typename T> class async_fifo : public tlm::tlm_blocking_get_if<T> // whatever fits your needs best , public sc_core::sc_prim_channel { sc_core::sc_host_mutex mtx_; // host-locking (e.g. pthread_mutex) sc_core::sc_event written_; std::deque<T> pushq_, popq_; public: async_fifo( const char* nm ) : sc_core::sc_prim_channel(nm) {} /* implement SystemC side interface (e.g. tlm_blocking_get_if) based on pop-queue */ void write_async( T const & v ) { { sc_core::sc_scoped_lock lock( mtx_ ); // critical section pusq_.push_back( v ); // append new value to queue } async_request_update(); } private: void update() { sc_assert( ! popq_.size() ); // make sure, everything is consumed by now { sc_core::sc_scoped_lock lock( mtx_ ); // critical section popq_.swap( pushq_ ); // move all pending tokens to pop-queue } written_.notify( sc_core::SC_ZERO_TIME ); } }; // async_fifo In David's original example, m_delay is indeed not fully protected. But as he already pointed out, you may miss updates (and notifications) anyhow. On the lower level, the compiler should be able to update m_delay in a single instruction, which at least prevents broken values. (You may want to check the assembly for this.) Greetings from Oldenburg, Philipp
  7. Oh, sorry. My mistake. The mentioned test has not been part of the 2.3.0 release. There may be some similar test included in the next version of SystemC… For now, you should use David's example as a reference. As in any (host) parallel programming, make sure to properly protect any shared data used in both parts (SystemC and other OS threads). This is not automatically addressed by the async_request_update mechanism. Sorry for the noise, Philipp
  8. There is no real tutorial example available, yet. But you can look at the SystemC regression tests [1], which have a small test included at tests/systemc/1666-2011-compliance/async_request_update/ Greetings from Oldenburg, Philipp [1] http://www.accellera..._2-3_2012-07-02
  9. You seem to assign a value bigger than 31 to a 4-bit sc_uint, and you have built your SystemC library with DEBUG_SYSTEMC defined. With this symbol defined, the library adds some additional bound (and value) checks. To add a breakpoint in your debugger, you may need to add the namespace to the symbol as well: b sc_core::sc_interrupt_here Alternatively, you can break on the reported file:line position directly (since you know precisely, which error you want to look at). Greetings from Oldenburg, Philipp
  10. You seem to use sc_signal<std::vector<unsigned int> > in your code. This should have been sc_signal<CDMAVec<unsigned int> >. The overall discussion has been, how to send something like a std::vector via a signal. With CDMAVec you have built such a class template. You should use it… /Philipp
  11. Gurunath, Torsten, The "name" parameter needs to be passed as const-reference const std::string&, since the stringstream returns a temporary object which can't be bound to a non-const reference. The "inline friend definition" used by Gurunath does not define a member function. It should work as expected and will be selected via argument-dependent lookup. Greetings from Oldenburg, Philipp
  12. Some general remarks on your code: This is a quite complicated way to compare two arrays. A shorter way, following the same idea, would be unsigned int check = 0; for( ; check<MOD_SIZE && data[check] == cd.data[check]; ++check ) { /* empty */ } return (check == MOD_SIZE); These functions should either be defined within the class as "inline friend" (as in "CDMAVec<X>") or be put into a "correct" namespace ("sc_core" for "sc_trace", or in the namespace of cdma_data.). I think you need to provide unique names for the individual traces, which means you need to append the index of the element correctly. Something like the following could work: for (unsigned int i = 0; i < MOD_SIZE; i++){ std::stringstream str; str << name << ".data_" << i; sc_trace(tf, cd.data[i], str.str() ); } General recommendations: don't use "using namespace" in header files don't inherit from std::vector publicly (it is not designed for polymorphism) // using namespace std; template <class X> class CDMAVec : protected std::vector <X> { typedef std::vector<X> base_type; typedef CDMAVec this_type; public: // make some parts of the interface public using base_type::value_type; using base_type::iterator; using base_type::const_iterator; using base_type::begin; using base_type::end; using base_type::size; using base_type::operator []; using base_type::resize; using base_type::push_back; // no need for (empty) default constructor/destructor // ... }; Now we come to the really problematic parts of your code: There are several issues in this function: "CDMAVec & cv<X>" is syntactically wrong, it should have been "CDMAVec<X> & cv" (better use a local typedef like "this_type" in my example above) The body of the loop is broken in several ways. "name + j" won't do what you expect (and fail compile, if you're lucky) inline friend void sc_trace(sc_trace_file * &tf, const CDMAVec<X> & cv, const string & name) { // unsigned int j = 0; for (size_t i = 0; i < cv.size(); ++i){ // cv[i] -> sc_trace(tf, *cv[i], name + j); // j++; // - neither "c[i]->" nor "*cv[i]" makes any sense for the general case // - why j? std::stringstream str; str << name << "_" << i; sc_trace(tf, cv[i], str.str() ); } } The template parameter is missing. sc_in<CDMAVec<cdma_data> > data_in; Hope that helps, Philipp
  13. SystemC 2.0 is not supported on 64-bit Linux. Moreover, the standard compilers shipped with Ubuntu 12.04 are too recent to compile SystemC 2.0 (since the C++ compliancy checks are more strict now). You can try to look into forcing a 32-bit compilation (e.g. with the help of the "linux32" helper, see "man linux32" and an "-m32" added to EXTRA_CXXFLAGS). You can drop the inclusion of <ieeefp.h> and include <cmath> instead. I'd expect further errors, which you'll need to fix by yourself. Pay attention to the compiler error message, ask your favourite search engine and try to resolve the issue. It will need be some work. Good luck. It may be easier to fix Metropolis… Greetings from Oldenburg, Philipp
  14. Muhammad, please use proper "quote" blocks, when quoting earlier messages. Otherwise it's quite difficult to separate your reply from the previous text. You have not given enough further details. My crystal ball is quite unreliable these days, so I think you need to show some code (preferably wrapped in a "code" block to enable syntax highlighting). How does your process look like with the loop and the debugging statements included? How do you generate the stimuli? Show the relevant parts of your testbench. How do you start the simulation? With a plain sc_start() or with a fixed time? Show the sc_main function. Greetings from Oldenburg, Philipp
  15. It's quite hard to understand your answer without more details. What does this mean? How does a waveform "appear"? How do you generate your clock events? How do you start the simulation? How/when do you stop it? This is very hard to parse. What is the "first instance"? How do you "check manually"? Debugger? printf? How can the control flow "remain" in the else part? What is the clock frequency? It looks like you want to model a synchronous design, where you check the reset signal at every rising clock edge. I would expect to see an advance of the timestamp according to the clock frequency. Wild guess: Did you include the last line in the loop I posted above? I.e. do you have a wait() for static sensitivity on the input clock after your condition? Greetings from Oldenburg, Philipp
  16. According to the SystemC standard, an SC_THREAD process is indeed only started once. Once the function completes, the corresponding thread is terminated. If you want to keep it running, you need to put an (endless) loop inside the process body. Don't forget to put at least one wait() on each control flow path. Something like: void init::conv() { //it's C++ - prefer direct initialization over assignment sc_time Tint (tINT, SC_PS); //8000 sc_time Tact (tACT, SC_FS); //8ntCK and tCK is 4ns sc_time Tstab(tSTAB, SC_NS); //5 sc_time diff = Tint-Tact; while(true) // endless loop { if(!reset_i.read()){ wait(diff); //after diff, DCKE should be zero dcke_o.write("00"); wait(Tact); //after tACT (or initialization time), reset should be true reset_o.write(true); wait(Tstab); //after tSTAB dcke_o.write("11"); } else{ reset_o.write(reset_i.read()); //for normal operation } wait(); // wait for the next clock edge (required!) } } Greetings from Oldenburg, Philipp
  17. Ok, after having a closer look at your code, I know remember that a similar issue has popped up very shortly before the release of SystemC 2.3.0. On Microsoft VC++ something strange has been going on in the sc_concatref conersion to sc_big(u)int, which especially affects the comparison operator in certain corner cases. Your workaround is known to avoid this problem. Since a "hotfix" made it into the 2.3.0 release (see src/sysc/datatymes/misc/sc_concatref.h:247, and we have not observed this (or a similar) problem on other platforms, we need more information from your side: SystemC version (Accellera's 2.3.0, right?) platform, compiler, compiler flags compile/runtime warnings and errors a self-contained code sample, preferable less than 100 lines, demonstrating the problem Any valgrind and purify reported memory leaks are probably false positives here. Reported accesses to uninitialized memory may be a better indication for the bug's origin. Can you paste the (first) related error in this case? You can also download the SystemC regression test suite from the accellera.org website and check the systemc/datatypes/misc/concat/test07 test case, which has originally triggered the related issue on MSVC. Greetings from Oldenburg, Philipp
  18. A memory leak would not cause "random results". It would just consume more memory. Can you post some information about these "random results"? Secondly. whether or not a memory leak exists requires more details as well. The reports from Valgrind and Purify could be false positives as well, especially since there are memory pools used behind the scenes. Why do you suspect a memory leak here? Greetings from Oldenburg, Philipp
  19. If you look at the error message more closely, the problem is not caused by the existence of your "main" function, but by the missing sc_main function. The main reason for this is the preferred use of the dynamic library since SystemC 2.3.0. The dynamic libraries needs the sc_main symbol to be present, as you cannot decide during the (dynamic) linking step, if this function is actually called or not. Two solutions are possible link against the static library libsystemc.a (e.g. by moving libsystemc.so out of the way) add an (empty) sc_main Greetings from Oldenburg, Philipp
  20. The "NewVector" class proposed by AR/Ravi in the linked post is a class template already. Therefore, you should be able to define the missing functions (==,<<,sc_trace) for all datatypes T based on T's operations elementwise. sc_vector<T> is meant for vectors of SystemC object (moduls, signals, ports). The element type of a signal is not covered here. I'm not aware of any proposal to add a "signal-aware" element vector class to SystemC.
  21. The method process will be run once in the initialization phase of the simulation. [see 1666-2011, Section 4.2]. NB: Please try to post working code and wrap it in a [code] [/code] block to enable C++ highlighting.
  22. Just read the linked article, I posted in my earlier reply. You just can't use placement new with 'this' inside the constructor, period. You have not shown any reason, why you need to use delegating constructors. You can either use default parameters, or duplicate the constructor body, or use an intermediate base class, which always receives "all" constructor parameters No, you did not succeed. Your code still has "undefined behaviour", which just seems to work correctly. Yes, there is quite some magic in sc_module, like handling the SystemC object hierarchy, etc. That's what I said: you mess up the lifetimes of the internal (sub-)objects. It's just undefinied behaviour in C++ and you can't use this approach.
  23. It just means, what you already quoted: You can use your Loader_Scheduler, you just can't create new signals (or other primitive channels) dynamically during simulation.
  24. The feature you're looking for is called "delegating constructors" in C++11. It is not possible in C++03. Your solution is just plain wrong. You'd run the sub_module contructor twice, but the destructor would be run only once. See this article for a more detailed explanation of what happens. One option could be to use default parameters instead: sub_module( sc_core::sc_module_name n , int a = t1, int b = t2, int c = t3 ) : sc_core::sc_module(n) { // ... }
  25. It's a local problem, not related to SystemC itself. Make sure, that you have 'executable' permissions on this file (chmod a+x ...src/sysc/qt/config) the partition, you're building on, is not mounted with the "noexec" flag Greetings from Oldenburg, Philipp
  • Create New...