-
Posts
547 -
Joined
-
Last visited
-
Days Won
135
Content Type
Profiles
Forums
Downloads
Events
Everything posted by Philipp A Hartmann
-
Valgrind run on SystemC library.
Philipp A Hartmann replied to Niharika26's topic in SystemC Language
sim_input.h:344 and sim_sync.h:29 points to your code and the issue reported from sc_spawn_object is very likely caused via inlining from your Tasker::MethodFunction<> class. So you will need to look into your code to address these particular reports. For SystemC 2.3.1, the are some known Valgrind reports, most of which should have been addressed in SystemC 2.3.3. Greetings from Duisburg, Philipp -
SystemC TLM CMake install bug
Philipp A Hartmann replied to Asdruv's topic in SystemC TLM (Transaction-level Modeling)
Fix published in 5a94360d in the public repository. Hope that helps, Philipp -
Warnings of SystemC with pedantic CMake
Philipp A Hartmann replied to Hadrian2002's topic in SystemC Language
You can check against the latest master branch in the public repository, if the warnings have now been fixed. We tried to address at least some of the warnings in recent commits, see 292b25a df7f1f6 9a69d7c 5af8908 Hope that helps, Philipp -
Likely memory corruption by SystemC
Philipp A Hartmann replied to Oscar_Huang's topic in SystemC Language
Thanks for your detailed follow-up. We have now published a fix in https://github.com/accellera-official/systemc/commit/c1613d47, which will then be included in a future release of SystemC. Hope that helps, Philipp -
Hi Wim, Currently, cci_param<T> indeed does not support any of cci_value, cci_value_list, cci_value_map as value type T. The main reason is, that it would otherwise cause ambiguities in the API of cci_value(_list,_map) itself, if the generic conversion functions (which are used by cci_param internally) would support this. However, it might be possible to extend cci_param<T> to support this scenario explicitly. Greetings from Duisburg, Philipp
-
Short answer: You can't. See this answer from a related discussion: Greetings from Duisburg, Philipp
-
As the error message says, you have a failing assertion in your testbench code in adder_testbench.cpp, line 30 (emphasis mine): There is not much we can do about this without knowing your testbench and your model. Hope that helps, Philipp
-
You call tf->set_time_unit(1, SC_NS); without initializing tf before. Hope that helps, Philipp
-
Error: (E100) port specified outside of module
Philipp A Hartmann replied to VanTeo's topic in SystemC Language
As mentioned by the error message, you define a port outside of a module in the line above. -
Likely memory corruption by SystemC
Philipp A Hartmann replied to Oscar_Huang's topic in SystemC Language
Thanks for the report. I don't fully understand the summary, though. Some questions: Are the changes to the API check and/or the exception handling in sc_simcontext.cpp really needed? I would hope that removing/skipping the assert in sc_cor_qt.cpp is sufficient to work around the mprotect restrictions on CentOS 7+? Your instructions do not include --enable-shared=no, but your description says that you only(?) see it on a static SystemC library. Can you please clarify? To better understand the failing mprotect call in your environment, can you please provide the value of errno after the call? This can be obtained by adding something like: #include <errno.h> // ... ret = mprotect( ... ); if( ret != 0 ) { int mprotect_errno = errno; printf( "mprotect errno: %d, %s\n", mprotect_errno, strerror(mprotect_errno) ); } IIRC, Linux generally allows calling mprotect on allocated memory. The memory needs to be properly aligned at a page boundary, of course. One option might be to allocate the stack memory via posix_memalign (if available) instead of new. We can also change the implementation to gracefully ignore a failing protection and only restore the permissions if the mprotect(...,PROT_NONE) call was successful earlier. This brings me to my remaining question: Which one of the mprotect calls actually fails: Is it the one removing the protection (PROT_NONE) or the one trying to restore them? Thanks, Philipp -
Multiple inheritance in SystemC, is it possible?
Philipp A Hartmann replied to katang's topic in SystemC Language
You have multiple instances of the "bundles" in your monitor class: inherited directly as additional members in the nested classes sim and stub To avoid the name clashes, you can make sim and stub modules themselves via: struct sim : sc_module , if_inputs, if_outputs { SC_CTOR(sim) {} } sim { "sim" }; -
I cannot comment on old SystemC versions like SystemC 2.3.1. I recommend to run the same with SystemC 2.3.3 instead.
-
sc_trace for sc_bigint<W> when W=1024
Philipp A Hartmann replied to Ness's topic in SystemC Language
Fix pushed to the public SystemC repository, see https://github.com/accellera-official/systemc/commit/3e4fc6e0e669c727fcbd46100ee1d7ba58ec5894. This fix will be part of a future release of the Accellera reference implementation. Thanks again for reporting the issue! -
Hi Rainer, thanks for your detailed report. The issue seems indeed an incomplete implementation of the CCI 1.0 LRM. I'll forward your finding to the Accellera CCI working group. To achieve the expected behavior, you can locally change the from_json implementation to something like: inline cci_value cci_value::from_json( std::string const & json ) { cci_value v; bool ok = v.json_deserialize( json ); if( !ok ) { // report CCI_VALUE_ERROR instead of using sc_assert v.report_error( "JSON conversion failed", __FILE__, __LINE__ ); } return v; } Local error handling on the calling side then looks like: cci::cci_value v; try { v = cci::cci_value::from_json(string); } catch (... ) { // catch CCI value errors only, others are re-thrown cci::cci_handle_exception( cci::CCI_VALUE_FAILURE ); // customize error behavior, e.g. via SC_REPORT_WARNING( ... ); } Thanks and Greetings from Duisburg, Philipp
-
bfloat16 data type
Philipp A Hartmann replied to Hariharan Bhagavatheeswara's topic in SystemC Datatypes
There is no builtin support for custom-sized floating point types in SystemC. An open-source C++ bfloat16 implementation can be found here: http://half.sourceforge.net. I would expect that this works more or less out of the box in SystemC (maybe you need to implement a custom sc_trace overload). Hope that helps, Philipp -
max_num_extensions
Philipp A Hartmann replied to Khushi's topic in SystemC TLM (Transaction-level Modeling)
Hi Khushi, just adding to Eyck's answer, the "default" extensions in SystemC 2.3.3 are the following two implementation defined classes: tlm::tlm_endian_context tlm_utils::instance_specific_extension_carrier Greetings from Duisburg, Philipp -
Static Sensitivity to "AND" of two events
Philipp A Hartmann replied to ArjunMadhudi's topic in SystemC Language
Please be aware, that an sc_and_event_list does not imply that the events in the list are triggered at the same time. I would suggest to keep the only the clock sensitivity and act on the triggers in the body of the method instead: SC_METHOD(func2); sensitive << clk.pos(); dont_initialize(); // ... void func2() { if( nreset.posedge() ) { // nreset went high in this clock cycle // ... } } Alternatively, you can be sensitive to nreset.pos() and check for clk.posedge() (as a consistency check), if you don't have anything else to do in the body of the method. With this approach, you might be able to avoid unnecessary triggers of the method. Side note to Eyck: There's a small typo in the example above, which should should use "&=" to append to an sc_event_and_list. ev_list &= nreset; -
Port-to-port binding is not tracked by SystemC after elaboration is completed. You can try to restore (or at least approximate) the mapping yourself by checking "overlap" in the get_interface() results across ports and the hierarchical relationship between the ports' parent objects.
-
Changing the default writer policy requires to be set consistently throughout the whole application, which might be difficult with third-party infeeds. Since SystemC 2.3.2, you can also set the environment variable SC_SIGNAL_WRITE_CHECK=CONFLICT, which effectively enables SC_MANY_WRITERS at runtime (for all signals, though). Quoting the release notes: - [2.3.2] Add support for SC_SIGNAL_WRITE_CHECK=CONFLICT Instead of disabling all runtime signal write checks via the environment setting SC_SIGNAL_WRITE_CHECK=DISABLE, setting the variable to SC_SIGNAL_WRITE_CHECK=CONFLICT allows detecting conflicting writes to a signal within a single evaluation phase (see INSTALL).
-
Won't you have multiple drivers anyway as soon as you have a second initiator accessing your transactor? I would recommend to switch your pin interface to use sc_export<sc_signal_*_if<T> > instead of plain signal ports and bind signals with an SC_MANY_WRITERS policy internally. These signals also have constructors that allow initialization to a non-zero value without triggering an event at the start of simulation.
-
how can i know which event triggered a process?
Philipp A Hartmann replied to Ramarao V's topic in SystemC Language
If your company is an Accellera member already, I encourage you to join the SystemC language working group. Otherwise, you can find some documentation about the changes in the RELEASENOTES file of each release (although this particular feature seems to miss an entry :-/).