Philipp A Hartmann

Members
  • Content count

    354
  • Joined

  • Last visited

About Philipp A Hartmann

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling
  • Location
    Duisburg, DE

Recent Profile Visitors

490 profile views
  1. Maybe we can just reject "--enable-pthreads" on this platform explicitly. Generally speaking, you usually want to avoid pthreads, also on Linux, unless you have specific requirements. Greetings from Duisburg, Philipp
  2. Can you explain, why you try to use Pthreads on the Msys/MinGW platform? This environment doesn't come with a Pthreads library by default, you would need to install a separate one. And Pthreads will certainly be less efficient than the WinFiber-based process implementation. Thanks, Philipp
  3. Thanks for the reproducer, Sumit! This is indeed a regression compared to SystemC 2.3.0. I'll forward the issue to the SystemC Language Working Group. Greetings from Duisburg, Philipp
  4. The instance specific extension is tied to a specific accessor object (usually a member in a module, e.g. an interconnect). So each accessor can have its own extension object and is responsible for cleaning it up later. For regular TLM extensions, yes, there can only be one extension object of each type in a transaction payload.
  5. You can have a look at the "nb2b_adapter" test in the SystemC regression test suite, located at tests/tlm/nb2b_adapter/nb2b_adapter.cpp. In this example, you find the usage of an instance-specific extension for exactly that purpose: struct route_extension: tlm_utils::instance_specific_extension<route_extension> { int id; }; // ... virtual tlm::tlm_sync_enum nb_transport_fw( int id, tlm::tlm_generic_payload& trans, tlm::tlm_phase& phase, sc_time& delay ) { route_extension* ext = 0; if (phase == tlm::BEGIN_REQ) { ext = new route_extension; ext->id = id; // <-- store ID in the extension accessor(trans).set_extension(ext); } // ... virtual tlm::tlm_sync_enum nb_transport_bw( int id, tlm::tlm_generic_payload& trans, tlm::tlm_phase& phase, sc_time& delay ) { route_extension* ext = 0; accessor(trans).get_extension(ext); sc_assert(ext); tlm::tlm_sync_enum status; status = targ_socket[ ext->id ]->nb_transport_bw( trans, phase, delay ); // use ID from the extension Hope that helps, Philipp
  6. In line 33 of your producer.h, it seems you accidentally try to copy an interface (something derived from sc_interface). In order to give more detailed feedback, please share the code around the offending line. Hope that helps, Philipp
  7. Hi Sumit, even if the sockets are optional, you still need to bind at least one socket callback, right? Can you please check, that you actually do this? Greetings from Duisburg, Philipp
  8. On modern GCC versions (starting with 5.x), you the binary interface changed between C++03 and C++11 mode. You need to build your SystemC library with the same compiler (settings) to get the C++11 version of the functions. Hope that helps, Philipp
  9. 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
  10. 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
  11. 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, 7.10.12.2: 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
  12. 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
  13. 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
  14. 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
  15. 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