Jump to content

Frank Poppen

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Frank Poppen

  1. Oh, ... right I guess that would be true. Luckily, in my scenario I have just one initiator. Under this circumstances I was able to help myself with the second set of signals and the method inbetween as mentioned above. For the time being I will leave it the way it is. Once multiple initiators start to be relevant in our case I will definitely come back to your recommandation. Thanks for the help!
  2. I'm reading this thread and successfully tried 'start_of_simulation' and 'initialize', but as I expected, this did not solve my issue. I want to build a SystemC transactor translating READ/WRITE-TLM to a RAM into RTL "bit wiggles". This part was no problem for me. I implemented a b_transport that is being called by the requesting module and this b_transport is assigning the intended values to my transactor's sc_out (ram_en, ram_rw, ram_addr, ...) But until the first TLM arrives, the sc_out are not initialized. If I use 'start_of_simulation' or 'initialize' than I create a second driv
  3. (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
  4. 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 onl
  5. 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
  6. 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
  • Create New...