Jump to content

Philipp A Hartmann

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Philipp A Hartmann

  1. 1. Change the signal to an sc_buffer (triggers an event upon every write): sc_buffer<bool> sig; 2. Add an event to the controller, wait for it in controller thread, notify it from increase method sc_event sensor_ev; // ... void Controller::controller() { while(true) { while(value == 0) // wait(); //this could/should wait for an event trigger fired by increase() instead. wait( sensor_ev ); if(value > 0) { value = 0; wait(20, SC_SEC); } Some_Other_Stuff(); } } void Controller::increase(){ //if(sensor == 1) { ++value; sensor_ev.notify( SC_ZERO_TIME ); // } } Something like this? It's not clear, if the actual "value" is important. If it is not, you can only use the event for internal synchronisation. Greetings from Oldenburg, Philipp
  2. Yes, it has. See http://lmgtfy.com/?q...version to COFF http://stackoverflow...le-invalid-or-c http://social.msdn.m...16-2bfc039faa80 Greetings from Oldenburg, Philipp
  3. Problems in the C++ standard library usually indicate a problem in your environment configuration. Make sure that the compiler options (inclusing #defines) used within your SystemC project match the ones used during the compilation of the SystemC library itself.
  4. Yes, this is correct and usually the right thing to do.
  5. It's quite hard to tell the actual cause of the crash from your description and from the stacktrace alone. I assume a memory corruption in your part of the code. Do you store references or iterators to elements in the deque? Those can be invalidated by operations on the container. Are you sure, the object has not been destroyed? Dangling references can be quite hard to track down. Do you have a custom copy-constructor, assignment operator, or destructor in your class? Then you probably need all three of them (rule of three), to make it work correctly. You should try to strip down your problem to a minimal, self-contained test case. Take your custom class and write a separate function trying to reproduce the problem. If this does not help, try to check the differences. Of course, you can post this example here to ask for feedback. Greetings from Oldenburg, Philipp
  6. Assuming you're using plain signal ports, you can use the event member function to check, whether a specific port has been triggered in the current delta cycle: sc_vector< sc_in< int> > in_vec; // ... SC_METHOD(proc); for( unsigned i= 0; i<in_vec.size(); ++i ) sensitive << in_vec[i]; // ... void proc() { for( unsigned i= 0; i<in_vec.size(); ++i ) if( in_vec[i]->event() ) std::cout << "in_vec[" << i << "] triggered." << std::endl; } Greetings from Oldenburg, Philipp
  7. You need to instantiate the sub-module as a member in the parent module. Modules are just regular C++ classes, same rules apply. SC_MODULE(module1) { SC_CTOR(module1) : mod0( "mod0" ) // initialise member in constructor { // ... } private: // sub-module member declaration module0 mod0; }; Greetings from Oldenburg, Philipp
  8. First of all, you should refer to the standardized API in the IEEE Std. 1666-2011, instead of looking at the source code of the proof-of-concept implementation. This way you make sure that your solution works in other standards-compliant implementations as well. I assume there are specific reasons, why you can't use a proper sc_port (e.g. sc_fifo_in/out), connected to the particular sc_fifo instance of interest? Looping through the design hierarchy to manipulate the model structure is a rather special case in SystemC. No. As you have seen in your tests, the add_static function is private and non-standard. It is an implementation artefact. Instead, you should spawn a process, which is then sensitive to the events. Processes are the natural way to specify event-triggered functionality in SystemC. If you need to keep a handle to an event, you can use a C++ reference (or pointer), instead of creating a new event instance. Events have "identity" and can not be copied or assigned. This is the case for many structural elements in SystemC. sc_event const & ev_ref = sc_fifo_obj->data_written_event(); In the easiest case, you can just create a plain SC_METHOD process, being sensitive to your event. Of course, this requires to wrap the "callback" in a module instance. To make sure your FIFO has been created already, you should create this process in the end_of_elaboration callback of the module: SC_MODULE( fifo_callback_handler ) { // ... void callback_process(); void end_of_elaboration() { // ... find fifo object SC_METHOD(callback_process); sensitive << sc_fifo_obj->data_written_event(); dont_initialize(); // do not run at start of simulation } }; You can also use dynamic processes (sc_spawn, sc_bind) to create processes dynamically during the simulation. See 1666-2011, Section 5.5. Greetings from Oldenburg, Philipp
  9. In order to help other users with similar questions in the future, please keep the original question/contents of the discussion, instead of deleting them add your solution as a reply to your own question, if you have been able to resolve the problem on your own Thanks & Greetings from Oldenburg, Philipp
  10. Side note: Can you try to keep your reply outside of the "[ quote ]" blocks? Otherwise, it's hard to parse what's new and what's quoted. It is as accurate as you can be in SystemC. As David said in his reply, the SystemC time is represented as a 64-bit value itself. You can adjust the resolution (as a power of 10) with the function call (before using sc_time for the first time!): sc_set_time_resolution( 10, SC_NS ); to increase the maximum simulation time (but lose local precision). In case of very big differences, I would suggest to generate a warning and ignore the notification. It is unlikely, that you need/want both very high time resolution (below a single clock cycle) and very long simulated time periods (several years). Greetings from Oldenburg, Philipp
  11. What about something like this: sc_time delay = (x+1) * sc_time(50,SC_NS) * (val_2 - val_1); Greetings from Oldenburg, Philipp
  12. Have a look at the (brief) introductions to TLM-2.0, given by John Aynsley at Youtube: [media=] For a more detailed coverage of TLM-2.0, you can watch more videos on the Accellera website, e.g. TLM-2.0 in Action The OSCI TLM-2.0 Standard and Synthesis Subset Greetings from Oldenburg, Philipp
  13. Do you see a comppiler error, or is the file physically missing on your system? The official release of the Accellera SystemC PoC simulator contains this file. Make sure you have correctly unpacked the archive. $ md5sum systemc-2.3.0.tgz c26b9116f29f1384e21ab8abdb2dd70f systemc-2.3.0.tgz Secondly, you need to add the top-level include directory (<install-directory>/include) to your compiler's include path during compilation, but this is needed for SystemC itself already. Greetings from Oldenburg, Philipp
  14. I would say, an "image" is already "binary" in most cases. For the other cases, you may find the following documentation very useful: How to Ask Questions the Smart Way Greetings from Oldenburg, Philipp
  15. First note: You should not run your simulations as the root user. If you want to link statically against SystemC (libsystemc.a), you need to add "-pthread" to your compiler and linker flags (on Linux). This dependency is caused by the "async_request_update" feature in SystemC 2.3.0. Alternatively, you can add "--disable-async-updates" to your SystemC configure options, if you don't need this functionality. Greetings from Oldenburg, Philipp
  16. There is no way to model an asynchronous reset with a thread process in SystemC 2.2. If you need to stick with the old version, I'm afraid you need to use method processes instead. Greetings from Oldenburg, Philipp
  17. How do you see, whether a value has a decimal or hexadecimal representation? Most probably, it is stored in some form of binary in the memory. ;-) But you can directly assign both hex literals (C++ feature) and hex strings (SystemC datatypes feature) to sc_uint variables: #include <systemc.h> int sc_main(int,char*[]) { sc_uint<32> pippo; // ... pippo = 0x2A; // assign from hex literal pippo = "0x0A2"; // assign from hex string std::cout << pippo // decimal value by default << "=" << pippo.to_string(SC_HEX) // SystemC hex representation << " (0x" << std::hex << pippo <<")" // C++ hex representation (with manual '0x' prefix) << std::endl; return 0; } Gotcha: In SystemC, hex strings are signed literals by default. When dealing with unsigned variables (sc_uint, et.al), you should make sure that the hex string contains a leading 0 to avoid unexpected sign extension, when converting from the hex string. Greetings from Oldenburg, Philipp
  18. Hmm, how would the grammar of "just a SystemC/TLM program" be simpler than parsing plain C++? I'd say that if you indeed would want to define a specific grammar for SystemC/TLM programs, this would be way more complex instead. IMHO, any (decent) SystemC/TLM language frontend needs to contain (or be based on) a plain C++ frontend. For detailed references to existing projects, you should check the references in the survey paper I mentioned. Greetings from Oldenburg, Philipp
  19. Ok, I think you have messed up the file permissions in your "objdir" directory by calling "configure" through sudo. (Why?!) You should start afresh by removing the "objdir" directory first, or try the following from within a "new" build directory. Call "configure" without the "CPPFLAGS=-fpermissive" (Where did you get that from anyway?), and compile as regular user. Afterwards you can install via sudo: ../configure --prefix=/usr/local/systemc-2.3 make sudo make install Greetings from Oldenburg, Philipp
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  • Create New...