Stephan Gerth

zsh: abort ./test Could you please retry from within a bash environment?

Hi Marco, could you please provide us your command lines for the SystemC installation as well as for the UVM-SystemC installation attempt? I have an Ubuntu 18 available for testing.

Hi! I'm assuming that you already installed UVM-SystemC via the configure, make, make install mechanism. To use the library afterwards it is similar to SystemC: Use -I, -L and -l to specify the locations of header, library search path and the library name. Re-using your line above: g++ -I. -I$SYSTEMC_INCLUDE -I$UVM_SYSTEMC_INCLUDE -L. -L$SYSTEMC_LIBDIR -L$UVM_SYSTEMC_LIBDIR -Wl,-rpath=$SYSTEMC_LIBDIR -o hello hello.cpp -luvm-systemc -lsystemc -lm

UVM-SystemC 1.0-beta3 was released for public review. Download available at https://www.accellera.org/downloads/drafts-review. Notable changes since 1.0-beta2: Register API Bugfixes & SystemC 2.3.3 support Ubus example Automatic objection mechanism

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 th

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.