Jump to content

Philipp A Hartmann

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Philipp A Hartmann

  1. Philipp A Hartmann

    SystemC 2.3:valgrind error

    Hi Jonas, for now, this is a known leak (as stacks from statically created processes are currently deliberately not deleted) and allocations from sc_core::sc_cor_pkg_*::create should be suppressed. (Dynamically created threads are not affected, so it is not a "real" leak). Greetings from Duisburg, Philipp
  2. Philipp A Hartmann

    Undefined behaviour in regression suite

    Hi Joshua, This could then indeed be a bug. I would expect that (sc_fix)(uint)-1 is a positive value? You say, that this is not the case? Thanks, Philipp
  3. Philipp A Hartmann

    Undefined behaviour in regression suite

    Hi Joshua, thanks for the report also from my side. I think, a better fix for the regression tests in question would be to use one of the explicit conversion functions in sc_fxval(_fast), see e.g. IEEE 1666-2011, b[i] = (ushort)(b[i-1].to_ushort() * i * -1); The other question would be: Is the undefined behavior actually triggered? The quoted code looks like the sc_fxval values should indeed be positive as they have been assigned from a positive (ushort) value. The resulting double value then definitely holds a number that fits back into the unsigned short. Can you elaborate? Greetings from Duisburg, Philipp
  4. Philipp A Hartmann

    Usage of Sc_event_or_list

    Hi Jean-Claude, in SystemC, there is currently no way to identify whether an event has been triggered during/before the current evaluation phase in the simulation. See e.g. http://forums.accellera.org/topic/4925-/(and other threads) for earlier discussions. Btw: I find allEvents a confusing name for an sc_event_or_list. To me, wait(allEvents) sounds like waiting for all events to be triggered, whereas an or-list will trigger if any event in the list is notified. Greetings from Duisburg, Philipp
  5. I'm afraid, we need a more detailed analysis / debugging from someone, who has access to such a platform. Otherwise, we can just disable QuickThreads on Cygwin again and select Pthreads consistently instead. @Ralph: Can you try hunting this down in a debugger? Thanks, Philipp
  6. Hi Ralph, I agree, that the change in 2.3.1 is in violation of IEEE 1666-2011. And this needs to be fixed for sure. For 2.3.2, it's currently most likely that we just restore the original behavior. On the question of how to simplify the usage of sc_bitref in boolean contexts, we might also look into "explicit conversion to bool", see for example http://stackoverflow.com/questions/6242768/is-the-safe-bool-idiom-obsolete-in-c11. This needs further exploration and discussions in order to avoid escapes as in 2.3.1. This could be added to either sc_bitref<sc_bv_base> (sc_bitref<sc_lv_base>) (sc_logic) For the first option, I see the least risk of breaking the 1666-2011 compliance. The other two options could have more unwanted side-effects. The IEEE 1666-2011 sc_bit_ref template argument looks like an oversight to me. Will add this to the errata for review in IEEE later. Thanks and Greetings from Duisburg, Philipp
  7. Hi csr18, Thanks for reaching out on this topic. Allowing a conversion from sc_bitref to bool has been added intentionally to 2.3.1 to address the use case discussed at http://forums.accellera.org/topic/1392-/. With "this", Ralph is referring to the issue of now failing comparisons (and other operators) with character and some other literals, which now silently changed their meaning. This has been an unfortunate oversight in SystemC 2.3.1: sc_dt::sc_bv<1> bv = "1"; sc_assert( bv[0] ); // works now, great! sc_assert( bv[0] != '0' ); // broken! We're currently investigating options to restore the behavior required by 1666-2011. Have you seen other misbehaviors? Thanks and Greetings from Duisburg, Philipp
  8. Philipp A Hartmann

    Initialization of nested sc_vector< sc_vector< > >

    You need to add the preprocessor symbol SC_INCLUDE_DYNAMIC_PROCESSES to your build setup to enable sc_bind in SystemC, e.g. on the compilar command-line: -DSC_INCLUDE_DYNAMIC_PROCESSES. hth, Philipp
  9. Philipp A Hartmann

    Initialization of nested sc_vector< sc_vector< > >

    You can use a custom "creator" to initialize elements of a vector with custom constructor parameters - here the inner vector. Something like this (assuming you have lambda support available): auto element_creator = [](const char* nm, size_t) // optional, depending on the "real" value type { return new sca_module(nm); }; size_t inner_size = 42; // adjust for your needs, could also be a vector of sizes element.init( outer_size, [&](const char* nm, size_t) { return new sc_vector<sca_module>( nm, inner_size, element_creator ); } ); If you don't have lambdas in your environment, you need to put the functionality in a custom function, e.g. static sc_vector<sca_module>* element_vector_creator(size_t size, const char* name, size_t) { return new sc_vector<sca_module(name, size); } // using sc_bind to pass in the size - placeholders needed for actual call element.init( outer_size, sc_bind(element_vector_creator, inner_size, sc_unnamed::_1, sc_unnamed::_2) ); Hope that helps, Philipp
  10. Philipp A Hartmann

    tlm_fifo content safety

    Which version of SystemC/TLM are you using? I'm afraid, there is a known issue in the 2.3.1 circular_buffer implementation. When the fifo is destroyed while there are still elements in it, the loop over the "to-be-cleared" items does not start at the right index. Instead, you need the following change: circular_buffer<T>::clear() { for( int i=0; i < used(); i++ ) { - buf_clear( m_buf, i ); + buf_clear( m_buf, (m_ri + i) % m_size ); } // ... In 2.3, there was another indexing bug related to resize, see http://forums.accellera.org/topic/1443-/. Hope that helps, Philipp
  11. Philipp A Hartmann

    Error: (E100) port specified outside of module

    Hi VanTeo, to me, the following line looks suspicious: You said, SCI_func inherits from sc_module, but you pass in a string constant to its constructor from the derived SCI class. This will disrupt the SystemC object hierarchy, as the corresponding sc_module_name argument will be destroyed too early. If you want to use the SC_CTOR macro, you should add a protected default constructor to the SCI_func base class, allowing to take the name from the current top of the naming stack. See IEEE 1666-2011, section 5.3.3 for more details about passing sc_module_name arguments through the inheritance hierarchy. Hope that helps, Philipp
  12. Philipp A Hartmann

    SC_REPORT_* Confusion

    There is a recommendation in IEEE 1666-2011 (8.3.1) on the format of the message type: The message types used in the SystemC proof-of-concept implementation currently do not follow this scheme in many cases, as the reporting mechanism predates the definition of the IEEE standard for SystemC. In order to maintain backwards-compatibility, the existing message type strings have not been adapted. There needs to be a distinction between different message types in order to allow custom actions, severities etc. for individual message categories. In order to adapt the SystemC kernel to the above scheme, we would essentially need the same "IDs" as we have right now, and would just add some "/../..." prefix to them. But this would require changes to all existing models working with the existing IDs today. Hope that helps, Philipp
  13. Philipp A Hartmann

    Selling tool written in SystemC 2.2.0

    To me, an Internet forum doesn't look like the best place to ask for legal advice. You might want to consult a lawyer instead. Greetings from Duisburg, Philipp
  14. Philipp A Hartmann

    -D_GLIBCXX_DEBUG makes systemc-2.3.0 crash

    I did a quick local check and can reproduce the issue on SystemC 2.3.0 (Debian GNU/Linux, X86_64, GCC 5.3.1). However, on SystemC 2.3.1, ../configure CXXFLAGS='-D_GLIBCXX_DEBUG' make -j4 check completes successfully. Can you try on SystemC 2.3.1 again? Please note, that not all changes are explicitly listed in the RELEASENOTES and the release includes quite some cleanups and might have accidentally "fixed" the bug along the way. Thanks for your report, Philipp
  15. Philipp A Hartmann

    Error with a large number of SC_THREAD

    You're welcome! I just wanted to do the search myself, as I vaguely remembered this discussion. Greetings from Duisburg, Philipp
  16. In your main.cpp, change lines 48-50 to call the function sc_trace, instead of trying to instantiate an object of type sc_trace_file. sc_trace/*_file*/(wf, initiator->a, "a"); sc_trace/*_file*/(wf, initiator->b, "b"); sc_trace/*_file*/(wf, initiator->c, "c"); hth, Philipp
  17. Philipp A Hartmann

    Further help needed with finding port that is not bound

    It looks quite strange to me that the error message states (sc_object) as the kind() info of the unbound port. If the port in question is a "regular" port, it should report (sc_port) or something more specialized than that. Do you use some special/user-defined port here? /Philipp
  18. Philipp A Hartmann

    Read from buffer without removing content

    You can use tlm_fifo<T>::(nb_)peek for that, see IEEE 1666-2011 (17.3). hth, Philipp
  19. You're right: sc_delta_count is in fact intended (and used) for exactly such use cases. Historically (i.e. pre 1666-2011), the delta count semantics were a bit different, as we didn't have sc_pause and the starvation policy for sc_start, yet. So by nature of an event-driven simulator, there simply was no "empty time advance" before. With the extensions added to 1666-2011, we tightened the semantics when the delta count is increased in order to maintain deterministic results of the same simulation, regardless of the "activation sequence" in terms of sc_start calls. Therefore, the delta count is no longer incremented in such "empty evaluation phases", which you can introduce manually by calling sc_start without anything happening in the model (except for the time advance, maybe). Thanks again for bringing this up, Philipp
  20. Hi Ivan, thanks for your follow-up and for the updated example. I also do not see a way to trigger this corner-case from within a process, i.e. without jumping to sc_main in-between (and then using event() in sc_main itself). Therefore, I'm not sure if it's necessary to change the current implementation of the sc_signal::event function. An alternative could be to add a way to explicitly check for "empty evaluation phases", i.e. whether sc_delta_count() yields the same value before and after the sc_start call. That said, you can add this check to your sc_main logic manually already today. This way, only users doing such step-wise simulations require to pay the cost of the additional checks. For the next version of the SystemC standard, we should still clarify this behavior in more detail. And yes, there is no standardized API to simplify the implementation of an event()-like functionality in a custom channel. With the corner case you describe, maybe there is now an interest to define such a function, also taking care of the "same simulation time" guarantee. But as I said above, another option might be to relax an implementation's requirements for this check to allow for the corner cases of empty evaluation phases via sc_main between time steps. Greetings from Duisburg, Philipp
  21. Philipp A Hartmann

    Installing systemc on Ubuntu

    To me, the incomplete transcript looks like a broken compiler installation. Please make sure to install a C++ compiler, e.g. sudo aptitude install g++-multilib If that doesn't help, please post a full transcript of the installation steps (your listing contains several typos, which are expected to fail). Markus, can you please share some details? The error you describe should have been fixed in SystemC 2.2.0 and later. Thanks, Philipp
  22. As Roman pointed out, these symbol clashes have been avoided since SystemC 2.3 by moving the embedded copy to the sc_boost namespace. In SystemC 2.2, you can try to get away with it by explicitly including all duplicate headers from the recent Boost version first, i.e. before including SystemC (hoping that the include guards have not been changed). For those files, where the include guards have changed, you need to explicitly #define the sentinels as well to hide their duplicate inclusion. There still be dragons, though. hth, Philipp
  23. Hi Ivan, I have some follow-up questions on this issue: Have you been able to reproduce it during a "real" simulation? Do you see a warning about an empty evaluation phase during the simulation? In your special case, you check for 'event()' from within 'sc_main' again and you don't really simulate at all (no processes are running). In this case, the delta count is expected not to advance. Thanks, Philipp
  24. Philipp A Hartmann

    Modules with optional (configurable) ports

    AFAIK, using ports with an "optional" port policy (SC_ZERO_OR_MORE_BOUND) is not well supported by synthesis tools either. But you can try inheriting structs with the port declarations depending on some template parameters (entirely untested): template<bool HasMorePorts = true> struct async_fifo_optional_ports { sc_out<sc_uint<BITS_FIFO_DEPTH> > num_items; protected: void drive_num_items(const sc_uint<BITS_FIFO_DEPTH>& v) { num_items->write(v); } }; template<> struct async_fifo_optional_ports<false> { protected: void drive_num_items(const sc_uint<BITS_FIFO_DEPTH>&) { /* empty */ } }; template< bool HasMorePorts > SC_MODULE( async_fifo ) , public async_fifo_optional_ports<HasMorePorts> { // ... }; hth, Philipp
  25. Hi Ivan, thanks for your report and your detailed analysis. From my understanding of your quotes of the IEEE 1666-2011 standard, I would say that this is a bug in the Accellera proof-of-concept simulator. IIRC, the wording (and implementation) around the delta count has been refined during the IEEE update to 1666-2011, which was required to ensure determinism under presence of new features like sc_pause. I'll take your report to the SystemC LWG to resolve this issue in the next release. Thanks again and Greetings from Duisburg, Philipp