Jump to content

rainer

Members
  • Content Count

    4
  • Joined

  • Last visited

About rainer

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Out of curiosity, Eyck, is this actually correct/safe to do with a std::list (or std::vector or similar)? My understanding is that void sc_trace(sc_trace_file* tf, const TraceList& var, const std::string& nm); would be called once when you're calling the sc_trace for the signal/port/... carrying the TraceList, and the kernel would then keep the references to the list's elements. Now, assuming that TraceList's internal std::list would actually hold a non-constant amount of objects during the simulation, I guess you would run into the problem that the references to its members that you passed to sc_trace would be left dangling once the std::list's elements are reallocated for whatever reason (not as likely with a std::list than with a std::vector, but still a problem). Additionally, as far as I understood this, VCD's cannot deal with a varying amount of elements to be traced. So, by my understanding, the proposed method would only be safe to use if the list is known to hold a constant amount of values throughout the simulation (including during startup). I'm not sure whether SystemC's tracing mechanism can deal with a is non-constant amount of elements to be traced at all.
  2. Hi Philipp, thank you for the quick answer and for taking care of this! BR, Rainer.
  3. Hi, I'm using cci_value::from_json(std::string const & json) to allow users to set model parameters. If the supplied json string is invalid JSON, ie. cannot be deserialized correctly, the function fails rather harshly in the CCI 1.0.0 PoC implementation -- it simply sc_assert()'s that the conversion was ok: inline cci_value cci_value::from_json( std::string const & json ) { cci_value v; bool ok = v.json_deserialize( json ); sc_assert( ok ); return v; } In SystemC 2.3.2, sc_assert() calls sc_assertion_failed() in case of a failure, which in turn, reports an SC_FATAL, the default action of which includes to abort() the program. In case of an invalid user input, it obviously makes more sense to actually handle the error. However, the best I could come up with to deal with the SC_FATAL is this: auto const old_actions = sc_core::sc_report_handler::set_actions(sc_core::SC_FATAL, sc_core::SC_THROW); cci::cci_value value; try { value = cci::cci_value::from_json(user_supplied_string); } catch (sc_core::sc_report &) { SC_REPORT_WARNING(...); return; } sc_core::sc_report_handler::set_actions(sc_core::SC_FATAL, old_actions); This seems kind of clunky for what I assume is a rather common operation. Is the use of sc_assert() an oversight or am I missing something here? As a side node, while I have to admit that I haven't read the CCI LRM in depth, it gives this description, which doesn't seem to agree with the implementation (emphasis mine): and Thanks, Rainer.
  4. gtkwave actually supports strings in VCD files as an extension (see, eg., https://sourceforge.net/p/gtkwave/support-requests/2/ and the sample VCD file thats attached). With hacking the kernel to support tracing strings, as Roman mentioned, this works well in SystemC (I wrote such a patch some time ago, but unfortunately don't have it available anymore). Still, this means that your model will only work with the patched kernel and the VCD will only display correctly in gtkwave. test.vcd
×
×
  • Create New...