Jump to content

Philipp A Hartmann

Members
  • Content Count

    487
  • Joined

  • Last visited

  • Days Won

    117

Everything posted by Philipp A Hartmann

  1. Philipp A Hartmann

    SystemC 2.3 installation problems on ubuntu

    In general, a failing libtool indicates a local problem with your environment. Please check for free space, directory permission, etc. You use a filesystem with sipport for symbolic links, right? (i.e. not NTFS, FAT32)? Do you try to cross-compile? That said, can you please post the output of the call (incl. the parameters given to) the 'configure' script? You somehow added -fpermissive to the compiler flags, which is a bad, if not very bad idea. /Philipp
  2. Philipp A Hartmann

    DCAST exception for SC_THREAD call in constructor VS2012-W8

    Make sure you have the RTTI-information enabled in your VC++ project and that the /vmg switch is added to your compiler settings. See INSTALL file in the SystemC package: http://msdn.microsof...y/we6hfdy0.aspx http://msdn.microsof...y/yad46a6z.aspx Greetings from Oldenburg, Philipp
  3. Philipp A Hartmann

    SystemC grammar

    SystemC(/TLM) is not a first-class language on its own. Instead, it is a C++ class library. Therefore, you can find the language definition in the C++ standard itself, see http://isocpp.org/std/the-standard). That said, you should probably not try to write a C++ parser from scratch. Instead, you may want to look at existing (open-source) parsers, like Clang/LLVM or GCC. There are several projects working on reconstructing the SystemC elements from a C++/SystemC model (SystemC frontends). There has been an overview paper at FDL'2010 about this (Maguet et.al, A Theoretical and Experimental Review of SystemC Front-ends"). Greetings from Oldenburg, Philipp
  4. Not without changing core parts of the kernel.
  5. Of course, Alan is right. You may have a functional error in your model, if B is blocked indefinitely. But of course this depends on what you are modelling. In SystemC 2.3, you can use the new process control functions (kill, reset, throw_it), to interrupt a blocked thread. See section 5.6.6 of IEEE Std. 1666-2011. For sending custom "interrupts", a user-defined throw_it may be the most appropriate solution. But beware, that your models may not be exception-safe and can leak resources or invalidate internal invariants if not coded correctly. SC_THREAD(A); SC_THREAD(; sc_process_handle B_handle = sc_get_current_process_handle(); //... // in A(): B_handle.throw_it( my_exception() ); // in B() try { C_socket->b_transport( ... ); // blocked by a wait internally } catch ( const my_exception& ex ) { // do some cleanup } Similarly, you need to make sure, that C can cope with being interrupted by an exception! Greetings from Oldenburg, Philipp
  6. Philipp A Hartmann

    Bug on ?: operator for sc_int class ?

    Yes, synthesis of C++ data types (like the SystemC ones) is hard and comes with a lot of corner cases. Although I don't know CAPH, two comments: You mention a "type inference phase". The rules for (integer) arithmetics are quite complex in C (and thus in C++). Make sure, that you get the integer promotion rules and the (un)signedness correct. This is quite hard to debug. Hopefully, a good C++ frontend handles most of the work for you here. Inserting the "correct" cast will be very difficult as well. You should rely on the unary operator '+' in this particular case instead: When you detect an expression in one of the operands, make the other one an expression as well by prepending a '+'. This should work for all reasonable arithmetic types and allows you to rely on the C++ rules. Moreover, it will be more efficient (during post-synthesis simulation). Greetings from Oldenburg, Philipp
  7. Philipp A Hartmann

    Bug on ?: operator for sc_int class ?

    It's not a bug in SystemC, C++, nor in your compiler. It's just a restriction of the conditional operator ?: in C++. As the compiler error tells you, you need to have expressions of the same type in both operands. The list of allowed conversions is quite restricted (see e.g. here). Now, sc_int<N> is of class type, whereas the arithmetics are done interallly based on 64-bit integral types. Therefore, you need to cast the result back to sc_int<N> explicitly, or trick both operands to be artihmetic expressions: x<0 ? sc_int<n>(-x) : x; or x<0 ? -x : +x; Greetings from Oldenburg, Philipp NB: I replaced the explicit subtraction "0-x" with a unary minus for clarity and efficiency.
  8. Philipp A Hartmann

    need of delta cycles for correct values

    Usually: yes. At least if you delay the request and data signals within your interconnect models by the same amount of delta cycles (e.g. by forwarding values via explicit processes instead of just port/signal bindings). /Philipp
  9. Philipp A Hartmann

    need of delta cycles for correct values

    Without seeing any details, you most probably need the delta cycles to allow the request line to drop to zero again. You need at least one wait statement on each control path in your process loop, to yield back to the simulation kernel (SystemC uses a cooperative scheduling approach). Without seeing the master code (and the interconnect models, etcpp.), it's quite impossible to say why you need two delta cycles, though. A minor question: How do you tell, if the signal "is kept high", when you only wait for two delta cycles between checking the request line? Your ISS runs without consuming any simulation time? You may want to rethink your synchronisation mechanism. Greetings from Oldenburg, Philipp
  10. Philipp A Hartmann

    sc_bind undefined

    To use the dynamic process features (like sc_bind and sc_spawn), you need to define the preprocessor symbol SC_INCLUDE_DYNAMIC_PROCESSES before including SystemC: #define SC_INCLUDE_DYNAMIC_PROCESSES #include <systemc> In SystemC 2.3.0, this should work reliably, even if SystemC has been already included before. To make sure that this define is in place at all times, you might want to add the define to your compiler options. Greetings from Oldenburg, Philipp
  11. Philipp A Hartmann

    Error in Simulation with NC-SC Sim ( Cadence )

    You can't call constructors in the class definition directly. You need to initialise members in the constructor: axi_master_transactor<> amt; axi_traffic_generator<> atg; SC_CTOR(axi_master_top) : amt("amt") , atg("atg", 2, 4, 0x0000000000000100, 1, 0, 8 ) { /* ... */ } Greetiings from Oldenburg, Philipp
  12. Philipp A Hartmann

    General Understanding

    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?
  13. Philipp A Hartmann

    General Understanding

    You run out of memory and a "new" expression throws an exception.
  14. Philipp A Hartmann

    2.3.0 with Visual 2010 "Unknown compiler"

    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
  15. 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
  16. Philipp A Hartmann

    Error in Simulation with NC-SC Sim ( Cadence )

    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
  17. Philipp A Hartmann

    async_request_update example

    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
  18. Philipp A Hartmann

    async_request_update example

    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
  19. Philipp A Hartmann

    async_request_update example

    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
  20. Philipp A Hartmann

    warning at simulation time

    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
  21. Philipp A Hartmann

    sc_signal<vector<T> >

    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
  22. Philipp A Hartmann

    sc_signal<vector<T> >

    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
  23. Philipp A Hartmann

    sc_signal<vector<T> >

    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
  24. 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
  25. Philipp A Hartmann

    process running only once?

    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
×