Jump to content

Search the Community

Showing results for tags 'context'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Accellera Systems Initiative
    • Information
    • Announcements
    • In the News
  • SystemC
    • SystemC Language
    • SystemC AMS (Analog/Mixed-Signal)
    • SystemC TLM (Transaction-level Modeling)
    • SystemC Verification (UVM-SystemC, SCV)
    • SystemC CCI (Configuration, Control & Inspection)
    • SystemC Datatypes
  • UVM (Universal Verification Methodology)
    • UVM 2017 - Methodology and BCL Forum
    • UVM SystemVerilog Discussions
    • UVM Simulator Specific Issues
    • UVM Commercial Announcements
    • UVM (Pre-IEEE) Methodology and BCL Forum
    • UVM 1.2 Public Review
  • Portable Stimulus
    • Portable Stimulus Pre-Release Discussion
    • Portable Stimulus 1.0
  • IP Security
    • IP Security Assurance Whitepaper Discussion
  • IP-XACT
    • IP-XACT Discussion
  • IEEE 1735/IP Encryption
    • IEEE 1735/IP Encryption Discussion
  • OCP (Open Core Protocol)
  • UCIS (Unified Coverage Interoperability Standard)
  • Commercial Announcements
    • Announcements

Categories

  • SystemC
  • UVM
  • UCIS
  • IEEE 1735/IP Encryption

Calendars

  • Community Calendar

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests


Biography


Location


Interests


Occupation


Company

Found 1 result

  1. Hi, I have some models built against SystemC-2.3.1. During simulation, I get an error telling me "in SC_METHODS use next_trigger() instead". I set a breakpoint there, and check cpi->kind. It's "sc_core::SC_THREAD_PROC_". I'm puzzled why the switch case pattern goes to the default case (in wait(const sc_time&t, const sc_event& e, sc_simcontext* simc) of the file sc_wait.cpp), which causes the error. At the same time, there's another odd thing. Through backtrace of GDB, I see #0 sc_core::wait (t=..., e=..., simc=0x399f010) #1 sc_core::sc_module::wait (this=0x3fee1d0, t=..., e=...) #2 my_module:my_thread (this=0x3fee1d0) #3 sc_core::sc_process_b::semantics (this=0x4046170) #4 sc_core::sc_thread_cor_fn (arg=0x4046170) #5 sc_core::sc_cor_qt_wrapper (arg=0x4046170, cor=0x46765e0, fn=...) #6 qt_blocki () So, it should be in the SystemC thread of my_module::my_thread. However, I checked sc_core::sc_curr_simcontext->get_curr_proc_info()->process_handle->m_name in GDB, it shows that it is the name of another thread. I checked the program with Valgrind. It only shows some invalid read, no error with write. Anything wrong?
×
×
  • Create New...