Jump to content

Frank Poppen

Members
  • Content Count

    5
  • Joined

  • Last visited

  • Days Won

    1

Frank Poppen last won the day on July 8 2017

Frank Poppen had the most liked content!

About Frank Poppen

  • Rank
    Member
  1. Frank Poppen

    function with wait

    (I asked the question below, but believe to already have found the answer now myself: "sc_get_curr_process_kind()". I will try and work with that.) I have continuing question on this one. I have a function that for some complex reasons that take too long to explain here has to execute a wait(0) to allow for an SC_STOP to be executed as soon as possible (ending the current delta cycle). In 99% of my scenarios this function is called from a context of a SC_THREAD and it works just fine. But in very rare cases I need to call this function from outside such a context (some constructor) and in these cases of course I get an error: "Error: (E519) wait() is only allowed in SC_THREADs and SC_CTHREADs" Is it possible to do something like: if (bool thisIsThreadContext){ wait(0); } else { // Do nothing }
  2. I found a bug in my legacy code that I needed to fix. Even though the bug was easily found the fix troubles me due to limitations of SCV. I have a (template) function "randomRangeEval"() which uses an scv_smart_ptr to choose a random value from a range ... template<typename T> // T expected to be double, sc_fix or sc_ufix std::string randomRangeEval(T rangeStart, T rangeEnd) { ... scv_smart_ptr< int > randomRangeValue; ... randomRangeValue->keep_only(rangeStart, rangeEnd); randomRangeValue->next(); ... using the "int" does of course only work for sc_fix/sc_ufix with limited bit width. The bug became apparent when working with bitwidth greater than that of "int". So what would fix the problem is the use of ... scv_smart_ptr< T > randomRangeValue; // where T is either the same sc_fix or sc_ufix as the range defined ... unfortunately I receive the problem at "randomRangeValue->keep_only" which is ... error: 'class scv_extensions<sc_dt::sc_fix>' has no member named 'keep_only' As I see from the code of SCV it seems that only allowed is ... bool char unsigned char short unsigned short int unsigned int long unsigned long long long unsigned long long float double string ... not ... sc_fix sc_ufix ... but even "long long" is not enough as I could have an sc_fix with let's say 96 bits. Any ideas?
  3. Not sure if I should have opened another topic. Decided to continue here. It seems that this type of "tampering with default actions" is more deeply distributed throughout SCV. My testcases intentionally (at least I accept it) trigger an scv_random_error -> "RANDOM_OUT_OF_ORDER_SEED". This ends up in a call to _scv_message::setup() where I find in line scv_report.cpp::97 the following: scv_report_handler::set_actions(SCV_FATAL,SCV_LOG|SCV_DISPLAY|SCV_CACHE_REPORT); Once again the default behavior is changed and I'm wondering here why my fatal messages do not end the simulation as expected.
  4. My SystemC-Code is using messages of severity "Error" to intentionally throw exceptions. Suddenly I realize that no longer exceptions are thrown. Analyzing this issue, I targeted the function in my code "scv_random::seed_monitor_on(true, "../../Source/seedfile.txt");" to be the cause of this. For my current scenario I screwed up the path to the "seedfile.txt" which results in an error in "seed_monitor_on()". In this "seed_monitor_on()" calls the following: cannot_open_seed_file() -> message() -> set_actions(SCV_ERROR,SCV_LOG|SCV_DISPLAY|SCV_CACHE_REPORT) Conclusion at it seems to me: In case of a file not found "seed_monitor_on()" removes throwing off exception ("SC_THROW") in ALL(!) cases of messages with severity "Error". I would consider this to be an unwanted global side effect and probably a bug. Or?
×