Jump to content

Stephan Gerth

Members
  • Content Count

    68
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by Stephan Gerth

  1. 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?
  2. 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?
  3. 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.
  4. 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.
  5. 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.
  6. 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/
  7. 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; }
  8. As a temporary workaround you could make "sc_event_or_list terminated_events" a member of top_uvm2.
  9. 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.
  10. 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());
  11. 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
  12. 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.
  13. 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.
  14. Hi all, SCV is considered now in maintencance mode. This means we will adapt it to issues with new compilers and build flows but we will not add new features. Currently we are focussing our effort on UVM-SystemC. Best, Stephan
  15. It seems that a forgotten comment in file src/uvmsc/factory/uvm_default_factory.cpp line 1044 seems to be the culprit. Only printing should be affected. However, we will check within the workgroup if other effects are to be expected. For now, changing if( !m_type_overrides.size() ) //&& !sorted_override_queues.size() ) to if( !m_type_overrides.size() && !sorted_override_queues.size() ) should solve your issue.
  16. Can you provide your whole command line for building SystemC & UVM-SystemC and your example?
  17. Hi! the missing configure script will be included in the next release. CMake build is not completely supported yet but is now on our bug tracker. Thank you for reporting!
  18. This is a known limitation, we ran into this issue last year too. If you look closely you will find commented macros in the scv_extensions mentioning sc_fixed and sc_ufixed. However, uncommenting these entry will not work as these seem to be leftovers from the early implementation dating back to around 2000 when first commits were publicly recorded. You will probably have to find a workaround for that at the moment. Adapting the scv_extensions does not look too trivial.
  19. What kind of problems do you run into? Basically you have to build the SCV library first. After that you can compile the examples via "g++ *.cc -L<scv_install_dir> -lscv -o example".
  20. There is an internal buglist for the developers but AFAIK this bug is not known yet. The minimal example would help alot figuring it out.
  21. Hi! We have now released an updated version of SCV which should fix this issue for you.. You can find it here: http://accellera.org/downloads/standards/systemc
  22. Hi! as in the previous alpha release you should call config/bootstrap beforehand. This will create a configure script for you. (This is mentioned in the INSTALL file around line 226.)
  23. We are working on releasing an compatibility update rather soon, probably this year.
  24. Hi Aixeta, this is already fixed in the upcoming release of the SCV. Meanwhile you can workaround by casting directly to sc_logic: sc_dt::sc_logic_value_t(this->_get_instance()->get_bit(i))
×
×
  • Create New...