Jump to content

Philipp A Hartmann

  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Philipp A Hartmann

  1. 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>.
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. While traversing, you should have realised already, that all ports (and the other SystemC objects) are derived from sc_object. But even more specifically, you can use a pointer to sc_port_base, the non-templated base class of all ports. That said, the port_wrapper you've shown won't work as is. You'd need to do proper type erasure. But even with that, you still need to instantiate the correctly templated ports/channels within your testbench. The step from a configuration file, i.e. some runtime data, to a (statically typed) C++ object then requires some kind of factory. hth, Philipp
  14. First of all: Yes, if you use MSVC 2010, you should rename/copy the msvc80 directory to msvc10 to allow enable the correct lookup of the SystemC.lib. But you currently don't come to this point. From the error message, it looks like you have the MSVC executable listed after the Cygwin command-line tools in your PATH environment variable. Obviously, the Cygwin link.exe doesn't understand the options of the MSVC LINK.exe. hth, Philipp PS: You should use SystemC 2.3.1 to avoid the warning about the unsupported compiler version. Secondly, a number of bugs have been fixed in this release.
  15. Well, but you tried to add these "members" from Python during the construction phase afterwards. /Philipp
  16. Quoting my earlier reply (emphasis added): "Otherwise, you can create a wrapper (or a derived class), with no own sc_object/sc_module members and construct the real SystemC module from within C++." The module/object hierarchy creation is closely related to the sc_module_name stack. Once the sc_module_name instance is destroyed (after the completion of your ExampleModule (base class) constructor), the "current module" is removed from this stack. Therefore, the ports you create afterwards can not be assigned to the correct module. Again, a workaround may be to create the ports via Python from within before_end_of_elaboration callback, where the module hierarchy is correctly restored without having a proper sc_module_name stack. The deprecated constructor comes from very old versions of SystemC (before the introduction of sc_module_name) and requires you to manually call the (similarly non-standard) function end_module after the creation of all sc_object members at the end of the constructor. Otherwise, your hierarchy will be messed up in case of multiple (nested) modules. I would not recommend this approach. Greetings from Oldenburg, Philipp
  17. As said before, you have to have an sc_module_name parameter in the (leaf) constructor of your module class hierarchy. Using the deprecated constructor will likely mess up your object hierarchy during elaboration. You can directly call such a constructor with a const char* argument, as you can implicitly construct an sc_module_name from a const char*. Maybe this is all you need. Otherwise, you can create a wrapper (or a derived class), with no own sc_object/sc_module members and construct the real SystemC module from within C++. hth, Philipp
  18. In your case, the Timer module (or a dedicated interrupt controller, wherever your "interrupt clear register" is located) would be responsible for actually writing to the interrupt signal. This can then be locally resolved to a single control process within the module. However, especially for interrupt signals, SC_MANY_WRITERS is a common use model. Note that SC_MANY_WRITERS is perfectly safe to use, because you are still not allowed to write to a signal from multiple processes in the same delta cycle (as that could lead to non-deterministic behaviour). /Philipp
  19. You can't let the second process write to the same signal (deassert) without using SC_MANY_WRITERS. (This wouldn't make much sense in real HW without additional logic either.) Solution: Restructure your design to have a single writer to each signal instead. Hard to be more specific with the available details. hth, Philipp
  20. Yes, the segmentation fault is caused by trying to access the terminated process instance (to format the error message), which has been deleted already. This problem will be fixed in the next public release of the Accellera proof-of-concept implementation. Thanks for your report, Philipp
  21. Why can't you just use a tlm_fifo instead, which already provides peek/poke? /Philipp
  22. Strictly speaking, it is your fault. Quoting 1666-2011, section 5.2.3 (sc_module, constraints on usage), emphasis mine: So the last variant posted by Ralph is the correct definition. /Philipp
  23. The events of an sc_signal are triggered during the update phase of the simulation. Therefore, you can't cancel the event from a SystemC process. What are you trying to achieve? Why are you sensitive to an sc_signal event, if you don't want to be triggered?
  24. You try to create a primitive channel (sc_signal, sc_fifo, ...) during the simulation. This is not allowed in SystemC. You have to create all of these channels during elaboration (i.e. before the simulation is started). hth, Philipp
  • Create New...