Jump to content

Philipp A Hartmann

  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Philipp A Hartmann

  1. As a general remark: You should push your HLS vendor to bundle SystemC 2.3.0 with their next release. It should be no problem, since there are very few changes that affect synthesisable code (or rather the synthesis of the models) in the first place. Secondly, there are some nice features for synthesis as well, like async_reset_signal_is (or even sc_vector, but this may be more difficult to support). Why bother? As I said in my previous post(s), you can silence the warnings originating from SystemC by using the -isystem switch:$ g++ -Wall -isystem ${SYSTEMC_HOME}/include ...If you insist to change the SystemC 2.2.0 implementation in that area, you can compare the differences in the sysc/datatypes directory between 2.2.0 and 2.3.0. This will show (in addition to quite some "real" bugfixes) the required changes to silence the operator precedence warnings. hth, Philipp
  2. I didn't try this very recently, but you can download the AC datatypes separately. I don't expect any particular problems to use them with SystemC 2.3. If there should be any issues, they should be easily fixable. If you already have company-wide installs, maintained by other people than yourself, why can't you just use the -isystem option in your compiler flags and be done with it? Accellera did the "right thing" and fixed the distribution. The version including the fixes is called 2.3.0. I fail to see how a version 2.2.1 would solve any of your problems. This version would not be "bundled" with the AC datatypes, you would need to convince your company to install it, you'd still have your "simulation / synthesis" mismatches (whatever your concern is, in that regard). Greetings from Oldenburg, Philipp
  3. When using a specific tool, you should stick with their SystemC version (and compiler) anyhow. If you want to do a separate simulation with a new compiler, why can't you use SystemC 2.3 for this? (Esp. synthesizable) SystemC models compatible with 2.2.0 should work fine with SystemC 2.3. You can add the SystemC headers via -isystem, instead of a plain -I to your compiler's include path. This way, warnings from these headers won't clutter the warnings originating from your model. I don't think that there will be a 2.2.1 version of the proof-of-concept library released by Accellera. The bandwidth in the LWG is way too limited to maintain more than one version of the proof-of-concept library. You should fix the "mutable reference" issues by dropping the "mutable" keyword in the reported lines. You'll probably need to add some missing headers as well, IIRC. The other warnings can be safely ignored (e.g. via -isystem). hth, Philipp
  4. No. Some future version of the ASI SystemC proof-of-concept implementation may add support for Clang, but there is no release schedule for this at the moment. Upcoming releases and their call for public review will be announced via these forums, though. /Philipp
  5. Kocha, Basically, your edit should work as expected. SystemC 2.3 is in fact tested with Clang >= 2.9. You should not edit the configure file, though. If you want to add clang++ to the detection script, add the case to configure.in and run autoreconf instead. Another option is to have symlinks for cc and c++ in your path, pointing to the Clang compilers. On my Debian workstation, I use the alternatives mechanism (see man update-alternatives) for cc/c++ to point to Clang: [philipph@tethys:~]$ update-alternatives --display cc | head -2 cc - manual mode link currently points to /usr/bin/clang [philipph@tethys:~]$ update-alternatives --display c++ | head -2 c++ - manual mode link currently points to /usr/bin/clang++ and then use../configure CC=cc CXX=c++ to configure SystemC for Clang.Greetings from Oldenburg, Philipp
  6. This is a plain C++ question. The meaning of this line is not specific to SystemC. The line defines a const (member) function, returning a pointer to const char (known as "C string"). In the implementation, the constant character string "Hello world" is returned. Greetings from Oldenburg, Philipp
  7. You should read up on C++ functions (and overloading) in general to learn about signatures. In the owning class of the simple_target_socket, a callback is registered instead of an explicit socket binding. One function is called reset_counter, the other one read_counter The stimulus class' socket (called read_increment) is bound in sc_main. But, as I said, the code is a rather bad example to learn about such basic things. /Philipp
  8. The increment_request_transport just implements the b_transport interface for this component. It is registered on the forward path with the simple_target_socket, as you can see in the constructor. The name of this callback function can be chosen arbitrarily, as you can see (as long as the signature matches). That said, you should not adopt the coding style of this example. The target is not supposed to modify the data pointer (just its contents). Even worse, a pointer to a local variable is returned, which just happens to work by chance and may break at any moment (undefined behaviour). /Philipp
  9. You're supposed to call the function, not to pass the function (pointer) to the bind call. Try something like sc_in<int> p_in; p_in( vh_const(42) ); You'll need to make sure that the parameter passed to vh_const matches the type of the port exactly, otherwise the binding will fail as well. If needed, you can add the type explicitly to the vh_const call: p_in( vh_const<int>(42L) ); // should work, even though argument is of type 'long' hth, Philipp
  10. I think, your error message does not match the code you've shown. The compiler complains about an sc_in, not an sc_out as you've shown in your code. For input ports, you can apply a similar trick, but instead converting to an sc_signal_in_if<T> const&. If you need to provide a non-zero constant value, you'll need to assign this value to the signal that is created before returning it for the binding. It can be done via a free-standing function then (to avoid duplicating the datatype template argument). Something like the following (untested) snippet: template<typename T> sc_core::sc_signal_in_if<T> const & vh_const( T const & v ) // keep the name consistent with vh_open { // Yes, this is an (elaboration-time) memory leak. You can avoid it with some extra effort sc_core::sc_signal<T>* sig_p = new sc_core::sc_signal<T>( sc_core::sc_gen_unique_name("vh_const") ); sig_p->write( v ); return *sig_p; } Which version of MSVC do you use? You may want to try a newer one instead... hth, Philipp
  11. Running your example program in a debugger prints the full expected information here: (gdb) print integer $1 = {<sc_dt::sc_int_base> = {<sc_dt::sc_value_base> = {_vptr.sc_value_base = 0x804a628}, m_val = 12, m_len = 30, m_ulen = 34}, <No data fields>} (gdb) print integer.m_val $2 = 12 Since some debugging information is present, I assume that the symbols in the linked library were not found. Read the INSTALL information that is part of the SystemC 2.3.0 package (quoting): ... Several options are available to the configure script to modify the compiler configuration and the selection of certain features: --disable-shared do not build shared library (libsystemc.so) --enable-debug include debugging symbols --disable-optimize disable compiler optimization --disable-async-updates disable request_async_update support --enable-pthreads use POSIX threads for SystemC processes As you can see, there are specific options supported by the configure script to build the library variant you want. You seem to want something like: ../configure --enable-debug --disable-optimize --prefix=/usr/local/systemc230 Some comments on your build process: This won't work reliably (if at all). You should never mess with (internal) configure/Automake variables via the environment. Pass them as arguments to the configure call instead. Secondly, use standardized user-customisation variables like CXXFLAGS here. ../configure --enable-debug --disable-optimize --prefix=/usr/local/systemc230 CXXFLAGS="-Werror" hth, Philipp
  12. Short answer: The standard requires an sc_trace overload for a user-defined (signal) datatype if and only if you actually trace this particular type. Defining the virtual function sc_object::trace would require an overload for each and every data type used within a primitive channel supporting traces, even if those signals are never traced. This would be quite inconvenient. /Philipp
  13. I agree with Alan here. Moreover, when you look at the backtrace, you'll most probably see that the problem is within the sender part: The name thread_p_2 refers to the third dynamically created process in this module. Based on your loop above, this would be the second sender process. You didn't show the body of the sender. That said, it is always a good idea to add explicit names to the design elements you create. Something like: sc_spawn( sc_bind(&hermes_with_pkt_codec_vhd_bfm::sender, this, i), sc_core::sc_gen_unique_name("sender") ); Greetings from Oldenburg, Philipp
  14. A small addition to Alan's nice explanation: If you don't target synthesis (which may not support this), you can avoid inconsistency errors due to the duplicated width information by using the arbitrary width base classes as well: result = sc_unsigned(sc_bv_base( rdata.range(127, 0) )) + sc_unsigned(sc_bv_base( wdata.range(63, 0) )); /Philipp
  15. You need to jump through a temporary bit-vector (at least for the widerer range), I'm afraid. You can try something like the following untested snippet sc_biguint<128> temp1 = sc_bv<128>(rdata.range(127,0)); temp1 += wdata.range(63,0).to_uint64(); result = temp1; Greetings from Oldenburg, Philipp
  16. I have two comments on the above snippet, assuming you're using sc_mutex. Firstly, your check should never print FAILURE, unless the unlock itself failed. Therefore, you should check for the return value of the unlock call instead. You need to unlock the mutex from within the same SystemC process you have locked the mutex from, otherwise the unlock will be rejected. Secondly, there is no delta delay required (or enforced) between the unlock and a subsequent lock. The pending lock calls (or any subsequent trylock during the same evaluation cycle) will succeed to lock the mutex again. The internal event used to notify blocked processes is triggered immediately, not within the next delta cycle. This may help to track down your problem. Greetings from Oldenburg, Philipp
  17. There is information about the connectivity in the above snippet. You just need to store the relation between the ports you find (optr) and the connected channels (optr->get_interface()) in an appropriate data structure that fits your requirements. HTH and Greetings from Oldenburg, Philipp
  18. The "right set of flags" obviously include (explicitly or implicitly) "-Wundef -Werror". From the C(++) preprocessor standard point of view, it is not a bug. All undefined symbols are supposed to be interpreted as 0: Side note: When using strict GCC compiler flags in your models (which is a very good idea!), you might want to include third-party libraries like SystemC as "system headers" to avoid such problems coming from external sources: $(CXX) $(CXXFLAGS) -isystem $(SYSTEMC_HOME)/include ... It is probably still a good idea to explicitly check for __SUNPRO_CC in sc_interface.h first. Thanks for reporting. Greetings from Oldenburg, Philipp
  19. Raul, ok, I can confirm your problem and this is a bug in the ASI proof-of-concept implementation. Thanks for reporting it, I'll forward it to the LWG to get it fixed in the next release. As a workaround, you can work around the issue by using sc_time and SC_SEC as time unit: // traceFile->set_time_unit(10, SC_US); traceFile->set_time_unit(sc_time(10, SC_US).to_seconds(), SC_SEC); Greetings from Oldenburg, Philipp
  20. I'd say, this depends on the X, you're supplying to the set_time_unit call. It is currently not enforced that this X needs to be a power of 10, according to 8.1.2 in the 1666-2011 standard. Can you post a minimal example demonstrating the problem? Opening a trace file, adding a single variable/signal, calling sc_start() and closing the file again should be enough. /Philipp
  21. You need to disable the problematc redefinition of 'for' in src/sysc/kernel/sc_cmnhdr.h, which used to work around a bug in an ancient version of MSVC. See attached patch. Greetings from Oldenburg, Philipp 0001-Check-for-MSVC-version-in-for-scope-bug-hack.patch.txt
  22. As I said in my previous post, nested classes are usually not a very good design pattern. Your example of the arbiter class is not very convincing either, as you may want to reuse (or replace) this arbiter as well. For a "real" use case of nested classes, you inherently need a very strong coupling between the outer and the inner class. Most likely, the inner class won't (or shouldn't) be used outside the implementation of the outer class. But this can of course include the above-mentioned SystemC-specific inheritance relationships as well. From the frontend/parsing point-of-view, you probably want to support such cases. If you want to (fully) parse the TLM-2.0 convenience sockets, you'll encounter an example of such a use-case. I'm not aware of SystemC-specific coding guidelines that talk about nested classes explicitly. From the (C++) language point-of-view, it's just another scoped identifier. Still, many widely adopted C++ coding guidelines discourage the use of nested classes. Greetings from Oldenburg, Philipp
  23. I'm not convinced, that SystemC is the language of choice for gate-level models. It's hard to tell what went wrong in your model without seeing the code (especially the process declarations and definitions) of the NANDs and their composition. Two short recommendations: Instead of printing out values, you should consider to trace the signals to a proper trace file. You may need to prevent the "forbidden" state in your flip-flop by adding "dont_initialize();" to some of your processes. /Philipp
  24. As in all C++ code, nested classes should be the exception, not the rule. I recommend the discussion given in the Google C++ Style Guide. My short SystemC-specific answer: In SystemC models, nested classes should not be defined. In SystemC methodology libraries (e.g. TLM-2.0, or your own support libraries), there are rare, but valid use cases for nested classes. Before discussing some of these exceptions, why do you want to use nested classes in the first place? /Philipp
  25. As explained in detail in my previous answer, the output you see is as expected. All of these reports (which are no errors in a strict sense) can be seen as false positives. The additional "possible loss" reported (the one with pthread_create in the call tree) is related to the stack allocation of your process. /Philipp
  • Create New...