Stephan Gerth

This seems a bit strange as GCC 4.2.1 would be horribly out of date while your Xcode/Clang dates from 2020. Anyway, can you please try to change the affected lines as shown and report back? sc_core::sc_signal<sc_dt::sc_lv<32>> paddr to sc_core::sc_signal<sc_dt::sc_lv<32> > paddr

Thanks Jagan! As I'm not familiar MacOS, can you provide what compiler + version are you using?

Hi Jagan! Can you provide some information from the output and/or logs which test actually fails?

Hi Ricardo! I think your assumption is correct: The GCC install in the Xcelium is probably pointing to the original compilation path of Cadence and therefore is not valid on your system. I can see this path in our installations too, which confirms it is not an issue of you using it wrong. As a permanent solution, you probably need to reach out to your IT to fix those path references to the actual locations.

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.