Jump to content

Philipp A Hartmann

Members
  • Content Count

    525
  • Joined

  • Last visited

  • Days Won

    126

Everything posted by Philipp A Hartmann

  1. The 2.0.1 LRM is very old. SystemC became an IEEE standard in the meantime, and luckily the same example is now part of the IEEE Std. 1666-2011 (see 7.10.1, Table 32). The ranges mentioned there match the ones you were expecting. Greetings from Oldenburg, Philipp
  2. As you may have noticed, only the exception-related SystemC classes (sc_report, sc_unwind_exception) use exception specifications (and only the plain throw()). These are required by C++03, see http://www.cplusplus.com/reference/exception/exception/. Have you experienced problems (except for potential deprecation warnings) in C++11 mode on some compilers (clang?). Can you share the compiler flags and the corresponding error messages? /Philipp
  3. Feel free to share the list of affected classes here. (I assume, it's mostly the pre-defined interfaces and channels being on that list). /Philipp
  4. In general, issues related to weak vtables are not that widely known, I think. Nevertheless, since this is only related to the compilation/(dynamic) linking performance of the library, I don't think that there is an immediate need for any changes to the proof-of-concept implementation. Commercial vendors may of course perform their own optimizations in this area. Greetings from Oldenburg, Philipp
  5. Sumit, thanks for reporting this. This part of the code is not used from within the standard API. Thus, I think it may be Ok to have this missing currently. If we'd wanted to fix this, we probably should add SC_CSD to the "not yet implemented" case here (to be safe). The proof-of-concept implementation of the standardised API uses other parts of the library for string conversions (including SC_CSD). Greetings from Oldenburg, Philipp
  6. You should make sure that SC_INCLUDE_FX is consistently defined through all header files, preferably by setting it on the compiler command-line (option -DSC_INCLUDE_FX). I would suspect that you included systemc.h already from somewhere else before defining SC_INCLUDE_FX locally. Did you try your example separately? It compiles mostly fine here, except for the fact that the module is called "rand" which locally shadows the "rand()" function, you try to call from the process. Greetings from Oldenburg, Philipp
  7. Sumit, yes, you can safely remove the storage class specifier "register" from sc_nbutils.h. It's only a hint for the compiler, and today's compilers usually now way better which variables to put in registers (and e.g. loop variables will probably end there anyhow). But why do you want to bother? Does your compiler complain about these? Please keep in mind, that this is still a reserved keyword in C/C++. You don't want to re-#define this token, do you? Greetings from Oldenburg, Philipp
  8. If I understand you correctly, you want to have a preprocessor switch: #if defined(DEBUG) # define PRINT_MY_DEBUG( Some, Args ) \ print_debug_impl( (Some), (Args) ) #else # define PRINT_MY_DEBUG( Some, Args ) \ ((void)0) /* empty statement */ #endif // DEBUG void print_debug_impl( ... ); // real function implementation In the example above, the preprocessor symbol DEBUG is checked, whether or not to enable calls to the print_debug_impl function through the PRINT_MY_DEBUG function macro. You can define such symbols in the source, or via the command-line of your compiler (usually "-D<symbol>[=<value>]", i.e. here -DDEBUG). hth, Philipp
  9. Indeed, you're right, Alan. I stand corrected. I apologize for the false allegations. /Philipp
  10. Well, did you actually try to browse the provided website? ;-) http://www.embecosm.com/resources/software//Philipp
  11. On the above webpage, I don't see any references to the original authors of this work. In the provided whitepaper the page, no author information is given either. On the other hand, the article is a verbatim copy of an older article from IP-SOC/2005: http://www.design-reuse.com/articles/12918/reusing-verilog-ip-cores-in-systemc-environment-by-v2sc.html (by Leila Mahmoudi Ayough, Ali Haj Abutalebi, Ali Iranmanesh and Moji Atarodi). I think, it would be polite to acknowledge the original authors explicitly. /Philipp
  12. In case you don't want to download files from unknown sources, you can build the Doxygen documentation from the SystemC source tree directly: cd $SYSTEMC_HOME make -C objdir doxygen # assuming the configure-created Makefiles are located in the ./objdir/ subdirectory Afterwards point your browser to docs/sysc/doxygen/html/index.html # SystemC 2.3.0 docs/tlm/doxygen/html/index.html # TLM 2.0.2 The Doxygen configuration file templates can be found in docs/*/doxygen/ as well, in case you prefer different options. Greetings from Oldenburg, Philipp
  13. Prasanna, yes, the time resolution is limited to femtoseconds in IEEE 1666-2011. It is even guaranteed that SC_FS = 0, which means you can't easily add an SC_AS to your own implementation without the risk of breaking models relying on the SC_[timeunit] enum values (provided that you even have access to the sc_time source code). Do you need these small time values for event notifications and/or delays? Then you're currently out of luck. In case you can control the overall simulation, then you can "slow down" the simulated time by a factor of 1000, interpreting seconds as microseconds. But this is of course dangerous, since some parts of the model may rely on the physical meaning of e.g. sc_time.to_seconds() values. If you need this small resolution for internal computations only, you can resort to your own time type with small conversion functions from/to sc_time, e.g. based on the to_seconds() function returning a plain double (and therefore relying on its physical meaning as well, see above). Greetings from Oldenburg, Philipp
  14. Hans, Yes, you can (no pun intended). Here, you try to pass pin by value, which invokes a (deprecated, non-naming) copy-constructor, taking a non-const reference to dbusin. Since the simulation is already running (as it is said in the error message), this port creation fails. Add the missing & to pass pin by const-reference (as probably intended anyway). /Philipp
  15. See IEEE 1666-2011, Section 4.2.12 (emphasis mine): In other words, even if an implementation chooses to use "real" OS threads to implement SC_[C]THREAD processes, the usual way to guarantee the above is to ensure mutual exclusion between the thread activations. Greetings from Oldenburg, Philipp
  16. The function to set attributes for TDF MoC elaboration is called set_attributes() (plural form). You should be able to find such an error quite quickly by either adding simple debugging messages ("printf-debugging") or by using a proper debugger. Greetings from Oldenburg, Philipp
  17. As said in my initial reply, you wouldn't be able to catch any dynamic sensitivity (next_trigger) with this approach. Secondly, how do you implement the suspension of the method "afterwards"? During the following update phase? This wouldn't catch any following immediate notifications of the "scheduled method" in the current evaluation phase. There are more fundamental problems to solve than "just" copying the static sensitivity. I would suggest to wrap the user function call in a helper function containing the interaction with your scheduler class, instead of using the process control statements. Alternatively, you can add a separate statement to mark a method as schedulable (but this would still not catch dynamic sensitivity in the user method): SC_METHOD( user_method ); schedulable(); sensitive << ...; // put _after_ schedulable() statement! // add to some base class, could eventually be implemented as a free function as well void schedulable() { // pseudo code static std::map<sc_process_handle, sc_event*> ev_map; // put in the scheduler sc_process_handle h = sc_get_current_process_handle(); sensitive << *(ev_map[h] = new sc_event); dont_initialize(); // create wrapper method SC_METHOD( sensitivity_method ); // mark "h" as runnable here // senstitivity in user code again } Greetings from Oldenburg, Philipp
  18. Sam, That's not fully correct. In C++, you can't (directly) consider the return-type of a function (e.g: for overloading) to adapt the behaviour. You need to resort to intermediate values instead. In case of sc_fix(ed)/sc_fxnum, this intermediate value is sc_fxval, a variable-precision fixed-point value. Objects of this type always carry the required amount of bits during run-time and the assignment to another finite-precision type (sc_fxnum et.al.) handles the quantisation and overflow. AFAICS, you want to build a container class template for arithmetic types that provides element-wise operators. In order to deal with such intermediate values, there are several options depending on the level of generality you need to achieve and the constraints on the C++ language features, you can rely on. Disclaimer: The following snippets are fully untested. Simplest solution: Return a Vector<sc_fxval> instead (and provide an appropriate assignment operator/conversion constructor): Vector<sc_fxval,N> operator>> (unsigned m) const { Vector<sc_fxval,N> tmp; for (int i=0; i<N; i++) tmp.m_array[i] = m_array[i]>>m; return tmp; } Of course, this will limit the use of this shift operator in your Vector template to classes, where the result of the shift operator on the elements can be reasonably converted to sc_fxval. As a second option, you can use C++11's decltype and new function declaration syntax: auto operator>> (unsigned m) const -> Vector< decltype(T() >> m), N > { typedef decltype( T() >> m ) return_type; Vector<return_type,N> tmp; for (int i=0; i<N; i++) tmp.m_array[i] = m_array[i]>>m; return tmp; } This should work correctly for arbitrary shift operators and return an array of shift results. Since your compiler may not support these shiny new features of C++11, you can use a traits class with (partial) specialisation: template< typename T > struct vector_element_traits; // partial specialisation for sc_fixed template< int WordLength, int IntegerWordLength, sc_o_mode Overflow, sc_q_mode Quantization > struct vector_element_traits< sc_fixed<WordLength, IntegerWordLength, Overflow, Quantization > > { typedef sc_fxval right_shift_result; }; // ... Vector<typename vector_element_traits<T>::right_shift_result,N> operator>> (unsigned m) const { Vector<typename vector_element_traits<T>::right_shift_result,N> > tmp; for (int i=0; i<N; i++) tmp.m_array[i] = m_array[i]>>m; return tmp; } Last but not least, you can defer the evaluation of the element-wise operator by using expression templates to the implementation of the assignment operator of the vector. But this may be a bit too advanced for tonight. ;-) Greetings from Oldenburg, Philipp
  19. Minor addition: According to 1666-2011, Section 7.9.2.7, an explicit comparison with bool should work for bit-selects: if( bv[0] == true ) /* ... */ ; This doesn't look too bad, does it? HTH, Philipp
  20. Sorry for the late reply, but let me try to shed some light on this. Internally, the sc_bitref(_r) classes (which are returned by the operator[] of sc_proxy<X> and are (an implementation-defined) part of the standard) assume sc_logic as value type for both sc_bv and sc_lv. This is the main reason, why using bit-selects in boolean contexts is not directly possible. Adding an implicit conversion from sc_bitref_r and/or sc_logic to bool is not reasonable (and will likely cause ambiguities in existing models). Still, I agree that this is inconvenient and unexpected especially in case of sc_bv bit-selects. The best solution would be to update the bit-select (and range-select) definitions to inherit the value type from their underlying objects. This would require some refactoring of these parts of the standard and careful analysis of resulting backwards-compatibility problems. But since the internal conversions work fine is most cases, I would suggest to add a boolean conversion based on the safe bool idiom. The implementation would be fairly straight-forward (untested, to be added to sc_logic and sc_bitref_r): class sc_logic // or sc_bitref_r { typedef sc_logic this_type; // or sc_bitref_r typedef bool (this_type::*boolean_type)() const; // ... public: operator boolean_type() const { return this->to_bool() ? &this_type::to_bool : 0; } }; Of course, we still need to check for ambiguities or other unwanted side-effects. But since the comparisons should already be explicitly defined, it Should Work™. Greetings from Oldenburg, Philipp
  21. The link to the ebook is most probably a copyright violation (indicated by the embedded link inside). Please do not link to copyrighted material from this forum. @sonalidutta: can you please remove the link from your post? Thanks, Philipp
  22. IIRC, there is no standardized API to extract the (static) sensitivity of a process. On the other hand, since both SC_THREAD and SC_METHOD processes may use dynamic sensitivity in their process bodies, I'm not sure what problem this would actually solve (except for documentation purposes). What do you want to achieve? Greetings from Oldenburg, Philipp
  23. Brian, you ran into a (known) issue/corner-case regarding the new delta-cycle/sc_pause/sc_start semantics in IEEE 1666-2011. Regarding (1), see IEEE 1666-2011, Section 4.5.7: Regarding (2), a warning is required by IEEE 1666-2011 according to Section 4.3.4.2 (IEEE 1666-2005, i.e. SystemC 2.2.0 didn't have this functionality): In your case, the set of runnable processes is empty, but the set of update requests is not (due to the clk.write(1)). The generation of the warning due to an empty evaluation phase is somewhat beyond the spec here, since sc_pending_activity_at_current_time correctly returns true but no "real activity" is performed (except for processing the update phase). On the other hand, the value of sc_delta_count value is defined as: Therefore, it is reasonable to suppress the warning in this case. This is a minor issue in SystemC 2.3.0 and will be fixed in subsequent versions of the ASI proof-of-concept simulator. Until that, you can manually suppress the warning in your model by something like this: // helper macro for version checks #define SC_MAKE_VERSION( x, y, z ) \ (((x)*10000) + ((y)*100) + (z)) #if SC_MAKE_VERSION(SC_VERSION_MAJOR,SC_VERSION_MINOR,SC_VERSION_PATCH) <= SC_MAKE_VERSION(2,3,0) sc_core::sc_report_handler::set_actions( sc_core::SC_ID_NO_SC_START_ACTIVITY_, sc_core::SC_DO_NOTHING ); #endif Greetings from Oldenburg, Philipp
  24. Just a quick addition: In case the FIFOs do not receive their values symmetrically, you should wait for a data_written_event on any of the incoming FIFOs, in case of any FIFO being empty (i.e. after the loop). This can be done by using an or-expression on the ports: wait (in_port_1009->data_written_event() | in_port_10098->data_written_event()); // | instead of & If you want to avoid some unnecessary wakeups, you can optimize this by using an explicit sc_event_and_list (here, an and is needed again): sc_event_and_list written_events; // requires 2.3.0 if( !in_port_1009->num_available() ) written_events &= in_port_1009->data_written_event(); if( !in_port_10098->num_available() ) written_events &= in_port_10098->data_written_event(); wait( written_events ); Greetings from Oldenburg, Philipp
×
×
  • Create New...