Stephan Gerth

Hi Chethan, the issue you see comes probably stems from the driver and sequencer being created during the build phase when you start run_test(...). Your hierarchical logfile setting happens before that, so that the driver and sequencer could not know of that setting. To enable the wanted behaviour, you need to move the log setting to a later place in runtime or make the driver and sequencer full members of the environment.

Hi David, the failing test is expected, hence the 'XFAIL' and the green printing. The compile warnings are coming out of the SystemC library. According to the screenshots you are using an outdated version, can you please retry with SystemC 2.3.3?

Can you add delete _scv_tr_stream_core_p; at the end of the scv_tr_stream destructor in scv_tr.cpp, starting at line 736 and report if this solves the issue?

Hi PVR, this is probably the wrong sub-forum for that question. As your title suggests you are interested in SystemVerilog Assertions but this sub-forum is more oriented to SystemC verification. You probably will get more response about SystemVerilog Assertions in other forums such as https://verificationacademy.com/forums/systemverilog.

Looks like your libstdc++ found by the linker is not matching with your compiler version. Could you check that your LD_LIBRARY_PATH is setup correctly? As far as I remember GCC 4.1.2 is not the default system compiler version for SLES 11. So assuming that GCC 4.1.2 is probably residing in a different directory, you would have to adapt library search paths as well before running configure & make commands.

Done.

I'm a bit in favour of removing this check, albeit I'm not completely clear about the reasons why it was introduced at some point. If an event list gets destroyed by some means (module gets deleted, thread gets killed, explicit deletion via pointer, ...) any process which was still waiting on it should keep waiting (forever). The destruction of the event list should not raise a notification to waiting processes as this was probably not the expectation of them being notified.

Minimal example of the actual underlying issues posted here: http://forums.accellera.org/topic/6232-killing-a-process-with-an-included-sc_event_andor_list/

In reference to http://forums.accellera.org/topic/6218-wait-is-not-allowed-inside-run_phase/ I created a small demo which exhibits the same behaviour: create a process which waits on an event list which resides on its stack (and waits there forever) create a second process which, shortly after starting the simulation, will kill() the other process. This creates the following fatal message: This begs the question if this is intended behaviour or is some kind of bug: I guess in principle it should be possible to kill() a thread which is waiting on an event list. But if the event list object resides on its stack the above message is printed. If the objects is e.g. an object member, the simulation runs without error. Demo source: #include <systemc.h> SC_MODULE(top) { public: sc_event e; void thread_1() { wait(1,SC_NS); // be sure that thread_2 is already waiting t2_hdl.kill(); } void thread_2() { sc_event_or_list terminated_events; terminated_events |= e; sc_core::wait(terminated_events); // will never finish } SC_CTOR(top) { SC_THREAD(thread_1); SC_THREAD(thread_2); t2_hdl = sc_get_current_process_handle(); } sc_process_handle t2_hdl; }; int sc_main(int argc, char **argv) { top i_top("top"); sc_start(); return 0; }

As a temporary workaround you could make "sc_event_or_list terminated_events" a member of top_uvm2.

Further investigation seems to indicate that, when the process for the non-objected run_phase is destroyed its get_child_objects() list is empty. Thus, the spawned processes get not killed before the sc_event_or_list is destructed. Which in turn, raise the "prematurely destroyed" message. I could not reproduce this with plain SystemC, so a bug in UVM-SystemC is not ruled out, yet.

Interesting observation: The error is reproducible if you just add one process to the "terminated_events". But if I replace the list (which has only one event now) within the wait statement with the concrete terminated_event() of that process it works as expected (kind of, as we have now only one process): Replacing sc_core::wait(terminated_events); with sc_core::wait(sc_spawn(sc_bind(&top_uvm2::fun1, this),"fun1").terminated_event());

Hi Kevin, you are missing the raising and dropping of an objection in the run_phase method (which would be required in SystemVerilog too) to prevent the early finish of the test sequence: void run_phase(uvm::uvm_phase& phase) { phase.raise_objection(this); [...] phase.drop_objection(this); } By adding this I get the desired result: UVM_INFO @ 0 s: reporter [RNTST] Running test ... run: before fork/join Current time is 0 s =========== fun1======== Current time is 0 s =========== fun2======== Current time is 20 ns run: after fork/join Current time is 60 ns UVM_INFO ../../../../uvm-systemc-1.0-beta2/src/uvmsc/report/uvm_default_report_server.cpp(666) @ 60 ns: reporter [UVM/REPORT/SERVER] --- UVM Report Summary --- ** Report counts by severity UVM_INFO : 1 UVM_WARNING : 0 UVM_ERROR : 0 UVM_FATAL : 0 ** Report counts by id [RNTST] 1 UVM_INFO @ 60 ns: reporter [FINISH] UVM-SystemC phasing completed; simulation finished

I assume that by this term an empty verification IP is meant. So you would have just to fill in specific functionality such as e.g. the driver interface, monitor interface, items, sequences, etc.

Hi! This actually depends on how you implemented your agent and how you implemented its configuration abilities. This is more a general UVM design question and not strongly UVM-SystemC related.