Jump to content

Philipp A Hartmann

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Philipp A Hartmann

  1. Hi Ivan, I have some follow-up questions on this issue: Have you been able to reproduce it during a "real" simulation? Do you see a warning about an empty evaluation phase during the simulation? In your special case, you check for 'event()' from within 'sc_main' again and you don't really simulate at all (no processes are running). In this case, the delta count is expected not to advance. Thanks, Philipp
  2. AFAIK, using ports with an "optional" port policy (SC_ZERO_OR_MORE_BOUND) is not well supported by synthesis tools either. But you can try inheriting structs with the port declarations depending on some template parameters (entirely untested): template<bool HasMorePorts = true> struct async_fifo_optional_ports { sc_out<sc_uint<BITS_FIFO_DEPTH> > num_items; protected: void drive_num_items(const sc_uint<BITS_FIFO_DEPTH>& v) { num_items->write(v); } }; template<> struct async_fifo_optional_ports<false> { protected: void drive_num_items(const sc_uint<BITS_FIFO_DEPTH>&) { /* empty */ } }; template< bool HasMorePorts > SC_MODULE( async_fifo ) , public async_fifo_optional_ports<HasMorePorts> { // ... }; hth, Philipp
  3. Hi Ivan, thanks for your report and your detailed analysis. From my understanding of your quotes of the IEEE 1666-2011 standard, I would say that this is a bug in the Accellera proof-of-concept simulator. IIRC, the wording (and implementation) around the delta count has been refined during the IEEE update to 1666-2011, which was required to ensure determinism under presence of new features like sc_pause. I'll take your report to the SystemC LWG to resolve this issue in the next release. Thanks again and Greetings from Duisburg, Philipp
  4. You can try s = dynamic_cast<sc_signal<bool> *> (v->at(0).get_interface()); Hth, Philipp
  5. Hi Markus, since SystemC 2.3.1, building/running the library with MinGW compilers has been validated (quoting the README): What errors do you see during configure? Greetings from Duisburg, Philipp
  6. I'd guess, that this is not a stack overflow but an out-of-memory issue, where the kernel fails to obtain enough memory for your processes. Maybe, you can switch your modeling style from SC_THREADs to using SC_METHODs, or even decrease the stack size as a first step? hth, Philipp
  7. SC_FORK/SC_JOIN can be used only within an already started process, not within the constructor of your module (SC_JOIN involves a wait as well). You can register the thread via SC_THREAD(my_thread); hth, Philipp
  8. You can pass the option --host=i686-linux-gnu to the configure call: mkdir objdir32 cd objdir32 ../configure --host=i686-linux-gnu --prefix=/usr/local/systemc230 # ... You need to make sure to have the g++-multilib package installed on Ubuntu. As a side note: You might want to install SystemC 2.3.1 instead, which includes some bug fixes. hth, Philipp
  9. Ok, it seems that the test itself fails to run (diff output indicates a missing run.log, not a missing golden.log). Can you please post the full output of running the test.exe in the objdir/examples/sysc/simple_bus manually? Maybe you can also attach a debugger and provide more information on the crash (if there is one)? That said, cygwin64 has never been tested and is not really supported by the Accellera proof-of-concept implementation. If possible, please report the results of running the full regression package (available at http://accellera.org/downloads/standards/systemc) on that platform, too. Thanks, Philipp
  10. Why do you need SystemC 2.2? Starting from SystemC 2.3.0, shared libraries are automatically built for the proof-of-concept implementation (on supported platforms). hth, Philipp
  11. First of all, "default time units" and all related functions are not part of the IEEE 1666 SystemC standard and are sometimes provided as deprecated features in the SystemC implementations. You should not use them. If you want to compute the number of cycles since the start of the simulation, you can store the clock period as sc_time value and divide the current simulation time by this period: sc_time now = sc_time_stamp(); sc_dt::uint64 cycle = static_cast<sc_dt::uint64>( now / clk_period ); Assuming that your package won't get older than 2^32-1 cycles, you should be able to store the lowest 32-bit of this cycle number and check for overflows during the age computation (i.e. new time is smaller than start time). hth, Philipp
  12. An initiator socket is first of all a SystemC port, enabling access to its bound interface (here of type tlm_fw_transport_if) via the operator->. Did you notice, that you call "socket->b_transport()", not socket.b_transport()? hth, Philipp
  13. Can you check, if the golden.log file has been copied correctly to the objdir/examples/sysc/simple_bus directory? On Cygwin, the symlinking detection is sometimes not realiably working... Alternatively, you can try passing 'LN_S=cp -a' (including the quotes) as option to the configure call. hth, Philipp
  14. As you've noticed and David confirmed, exports need to be bound to an interface implementation before they can be bound hierarchically. I've noticed that you implement the interface already in your "E_top" module (side note: you may want to inherit publicly from sc_module). In this case, you probably intend to bind this implementation to the export? in_port(*this); // <-- bind E_top implementation to export m_C_top.in_port(in_port); This is a fairly well-known modeling pattern together with exports. hth, Philipp NB: I would recommend to avoid using std::vector<bool>.
  15. As a final remark: No, you can't use sc_module as a virtual base class, not only due to the required casts to start/create the embedded SystemC processes. Your solution to split the implementation is correct. hth, Philipp
  16. Hi Stefan, thanks for your suggestion. The current choice is based on the practice to put arch-dependent .pc files to a pkgconfig subdirectory of the library dir (e.g. /usr/lib/pkgconfig). The correct location for your system may depend on the locally configured PKG_CONFIG_PATH, of course (quoting http://people.freedesktop.org/~dbn/pkg-config-guide.html, emphasis mine): Secondly, SystemC supports the installation for multiple target architectures to a single filesystem (via --with-arch-suffix or the classical installation layout). For this to work, it is required to put the generated systemc.pc files to arch-dependent locations. It should be possible to move the systemc.pc file to a location more suitable to your needs after the installation process of SystemC itself. Greetings from Duisburg, Philipp
  17. I agree that this restriction is currently not mentioned explicitly in the standard. The only related part I've found is mentioned in IEEE 1666-2011, (emphasis mine): That said, I tend to agree that the preparation of the local callbacks can happen too early. I'll take this issue to the TLM Working Group for further discussion. Thanks for reporting! Greetings from Duisburg, Philipp
  18. Since SystemC 2.3.1, you can easily configure optimization and the availability of debug symbols individually: ../configure --enable-optimize --enable-debug ... builds an optimized library with debug symbols without (significant) loss of performance. hth, Philipp
  19. The behaviour in SystemC matches the one in VHDL pretty closely: In VHDL, the outputs of a clocked process are also updated in the next delta cycle. How would would you model the desired behaviour in VHDL? That said, it seems you're somewhat mixing abstraction levels here, having an immediate notification (of thread B ) in an otherwise clocked system. If you indeed need to immediately reset C, you can explicitly call the 'reset()' function on (a process handle of) C from within thread B. This might still cause C to be evaluated twice, but at least now both runs would happen in the same evaluation phase. Hope that helps, Philipp
  20. I may completely miss the modeling intent, but if you want the process to be triggered upon each event notification or after ten nanoseconds at the latest, maybe you can use a wait with a timeout? wait(10,SC_NS); // startup? (trying to stay close to the original code) while(1) { cout << " Display ok"; wait( sc_time(10, SC_NS), event_1 ); // wakeup upon event_1, after 10ns at the latest } Would this help in your scenario? Greetings from Duisburg, Philipp
  21. Oh, there seems to be still an issue in 2.3.1, you should change the circular_buffer::clear function to template < typename T > void circular_buffer<T>::clear() { for( int i=0; i < used(); i++ ) { // buf_clear( m_buf, i ); // << BUG HERE buf_clear( m_buf, (m_ri + i) % m_size ); // This should(tm) be correct } m_free = m_size; m_used = m_ri = m_wi = 0; } Thanks for reporting. I'll take this to the Language Working Group to make sure a fix will be included in the next release of the proof-of-concept simulator. (I would still recommend to upgrade to 2.3.1... ) Greetings from Duisburg, Philipp
  22. AFAICS, this is another symptom of a known issue and fixed in 2.3.1. You should upgrade. Quoting the RELEASENOTES: Greetings from Duisburg, Philipp
  23. Tamilselvan, I had a quick glance and you're having signals with multiple drivers in your design (at least you're suppressing the related errors). There has been an issue in SystemC 2.3.0, fixed in 2.3.1, which could cause differences in this scenario. Quoting from the 2.3.1 RELEASENOTES: - Handle the case of a suppressed multiple-writer error in sc_signal (and related channels) consistently with SystemC 2.2.0 again. I would suggest to use the proper sc_writer_policy (i.e. SC_MANY_WRITERS) for these signals, if you really can't avoid having multiple SystemC processes driving them. Suppressing errors (or even warnings) is rarely the right thing to do. Greetings from Duisburg, Philipp
  24. The link order is incorrect. The dependencies are resolved from right to left. Your Makefile should say: # list SCV before SystemC LIBS = -lscv -lsystemc -lm # local objects first, then the required libraries $(TARGET): $(OBJS) $(CC) -o $@ $(LIBDIR) $(OBJS) $(LIBS) As a side note: For C++ applications, you should prefer the variables CXX (for the C++ compiler) and CXXFLAGS (for the compiler flags). CC and CFLAGS are intended for C projects. Secondly, I would recommend not to define DEBUG_SYSTEMC in user code. hth, Philipp
  25. You seem to misunderstand the relationship between templates and polymorphism here. Only the interfaces/classes that depend on a template type parameter are actually defined as a template. You're looking for something like dynamic typing (as known from languages like Python), where you could define a write method for different types without explicit overloads. This is not supported by C++ directly and you would need to build a mechanism for it on your own, if you really want this. Instead of just storing the sc_port_base pointer, you could store an adapter class, encapsulating the correct type conversion from some generic write parameter written by the testbench to the final C++ type used in the DUT. The adapter would then be constructed from the factory. Lookup "type erasure" in your favourite search engine. Still, this would only cover a specific channel interface (sc_port's template parameter), e.g. sc_signal_out_if for a set of compatible data types, e.g. sc_int_base for sc_int<N>. I'm not convinced that this simple architecture actually solves a real problem. Instead, you'd probably need to integrate something like the UVM driver concept on top of such a technique to orthogonalise concerns here. Theoretically, there is no need to recompile the testbench itself. Only the "missing" factory entries (i.e. adapter template instantiations) would need to be compiled and then linked to build the final simulation model. But yes, there's nothing you can do about this. But this is simply a consequence of C++ being natively compiled instead of dynamically interpreted. If you're just interested in signals of SystemC datatypes, you can also create a wrapper around your DUT and add adapters from the fixed-size types to their corresponding base classes (sc_int<N> -> sc_int_base, ...) and reduce the complexity of the problem. /Philipp
  • Create New...