Jump to content

Frank Poppen

Members
  • Content Count

    7
  • 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. 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 driver! One as part of my transactor and one more by the module that is making use of the b_transport. In other words: I cannot override the initial values and receive 'X' where the driven '1' and '0' collide. My plan is to have b_transport work on dedicated extra signals. My transactor initializes the sc_out (ram_en, ram_rw, ram_addr, ...). I will also implement another method, that shall be sensitive to the extra signals which will be toggled by b_transport. In this method I then assign the values of the signals to the sc_out. This way the driver to sc_out should be the transactor, only. QUESTIONS: Does it really have to be such a pain to implement a transactor by making use of such a mentioned method in between? And I did not try it yet, but I guess this should work?
  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 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 }
  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 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?
  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 expected.
  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 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?
×
×
  • Create New...