Jump to content

Philipp A Hartmann

Members
  • Posts

    538
  • Joined

  • Last visited

  • Days Won

    132

Everything posted by Philipp A Hartmann

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. It's a bit hard to tell, what the exact problem is, because you don't show the linker command issued from the Makefile. I would assume that the linking order between tlmSupport.a and SystemC (-lsystemc) is wrong and the SystemC dependency in tlmSupport.a can not be resolved correctly. Library symbols are resolved from right-to-left. Make sure to list tlmSupport.a before -lsystemc in the linker command-line. Since the problems seem to originate from the vendor-specific build system, please contact Imperas for support requests regarding OVP. Greetings from Oldenburg, Philipp
  11. Usually it is better to start a new topic in this forum, when there is a new question. Secondly, you should always provide the detailed error message given by the compiler. It is not entirely clear to me, what you are trying to achieve, because you do not show the all relevant parts of the code. Irrespectively of any tracing, you always need to connect the ports through appropriate channels (TDF or SystemC signals in your case). Last, but not least, a wild guess regarding the compiler error: In case you've copied the code directly to the browser and depending on your compiler version, you need to insert a space between the two closing template brackets: sc_core::sc_signal<sc_dt::sc_lv<8> > out; // space needed here ^ Hope that helps, Philipp
  12. SystemC 2.3 has been successfully tested on Ubuntu 12.04LTS (32/64 bit), which has GCC 4.6.3 and binutils 2.22 as default toolchain. Therefore, I don't think that there is a fundamental incompatibility between these tool versions. "some if/else expressions cannot be executed correctly" doesn't sound like a linker problem either. You can try, if the problem is reproducable in the SystemC regressions package, that can be downloaded from accellera.org. /Philipp
  13. I never had problems with binutils 2.22 (I currently use binutils-2.23 on my Debian workstation). But I usually don't use ld explicitly and let the compiler handle the linking as well instead. In general, more important than using some particular linker version is to use the same version for building/linking the SystemC shared library as for the final linking of the simulation executable. What "issues" do you see? /Philipp
  14. In general, a target socket needs to provide an implementation of the tlm_fw_transport_if<...> interface functions. An object implementing this interface needs to be bound to the socket during elaboration. For a more detailed answer, you need to provide more information. Is it a convenience socket? Is it your own socket? /Philipp NB: Worth reading: How To Ask Questions The Smart Way
  15. The sc_logic constructor taking a char is marked as explicit. Therefore, you can't pass a char to functions expecting an sc_logic (e.g. initialize). You can either explicitly create (pun intended) an sc_logic from a char, or use the predefined sc_logic constants for assignments and parameter passing: sc_logic a; a = sc_logic('1'); eoc.initialize( SC_LOGIC_0 ); // SC_LOGIC_1, SC_LOGIC_X, SC_LOGIC_Z Greetings from Oldenburg, Philipp
  16. I don't know the details of the OVP build system. You should probably consult the documentation provided by Imperas on how to add additional compiler and linker flags to the build. Why don't you just check what happens to the g++ call if you set the SYSTEMC_CXX_FLAGS variable? /Philipp
  17. Mehmet, "SYSTEMC_CXX_FLAGS" is a variable used in your local build scripts/Makefiles? Can you post the resulting compiler/linker calls? When building the SystemC library, you need to run the configure script first. When invoking this script, you can pass several options to it. One of these options is "--disable-async-updates". See INSTALL file in the SystemC package for more information. Greetings from Oldenburg, Philipp
  18. As Alan said, you can't initialize a class member within the body of the class definition in C++ (not SystemC specific). You need to write a constructor instead. Something like: template <sc_switch FIXPT> class abc { sc_fxcast_switch fxc; sc_fxcast_context fxc_context; // members sc_fixed<....> a, b, c; public: // default constructor abc() : fxc(FIXPT) , fxc_context(fxc) {} // ... }; Greetings from Oldenburg, Philipp
  19. Rajesh, Not necessarily. But this depends on your requirements and the rest of your interconnect model. I'd suggest that you do some experiments on your own. We can just guess, what your goals and constraints are. In case of persisting problems, you can post the relevant parts of your model and ask again. Greetings from Oldenburg, Philipp
  20. Rajesh, You can use a tlm_utils::eq_with_cb_and_phase (see 1666-2011, 16.3). Since the extension is already stored within the transaction payload, it is sufficient to insert the payload itself: // PEQ member of module "MyModule" tlm_utils::peq_with_cb_and_phase<MyModule> m_peq; // callback member function (assuming base protocol) void peq_callback( tlm::tlm_generic_payload&, const tlm::tlm_phase& ); // in constructor: reqister callback for PEQ SC_CTOR(MyModule) : m_peq( "peq", this, &MyModule::peq_callback ) // , ... { /* ... */ } // in nb_transport_fw, gp = current transaction payload // memory management, extension handling, ... m_peq.notify( gp, phase, delay ); // insert into PEQ // PEQ callback void MyModule::peq_callback( tlm::tlm_generic_payload& gp, const tlm::tlm_phase& phase ) { // extract extension from payload // ... } Greetings from Oldenburg, Philipp
  21. Generally speaking, a segmentation fault (and other related errors) occur within a user-space program when you try to access memory you are not supposed to access. This is not specific to SystemC. Instead of going into detail here, I recommend reading the Wikipedia article about segfaults at https://en.wikipedia.org/wiki/Segmentation_fault /Philipp
  22. Mike, there are several functions in SystemC to access/traverse the object hierarchy and analyze the individual elements: sc_get_toplevel_objects() sc_object::get_parent_object() sc_object::get_child_objects() sc_object::kind() (or C++'s dynamic_cast) sc_port_base::get_interface() You can find a description of their functionality in IEEE 1666-2011. See the following thread for some ideas: http://forums.accellera.org/topic/129-extract-structural-information-from-systemc/ Greetings from Oldenburg, Philipp
  23. Thanks for letting me know, that the download link is somewhat broken. I tried to fix it and it seems to be working here now. The link to the details page is https://complex.offis.de/documents/doc_details/29. In this presentation, several examples for "custom creator functions" are given. Personally, I prefer the variant of using sc_bind in combination with a local member function: // creator function (member function of surrounding block) subblock* request_scheduler_m::create_subblock( const char* nm, size_t idx ) { // call constructor with other parameters subblock* sub_p = new subblock(nm, param_1, param_2); return sub_p; } // initialize vector with custom creator subblock_vec.init( N, sc_bind( &request_scheduler_m::create_subblock, this, sc_unnamed::_1, sc_unnamed::_2 ) ); Using this variant of a creator, you can easily "store" and/or prepare the values of the module parameters within member variables of the surrounding module. Greetings from Oldenburg, Philipp
  24. Thomas, Implicitly, it has. Accellera Systems Initiative can not relicense the code (e.g. removing the choice of venue clause), because it does not own the full copyright. Obtaining permission from all past contributors is (close to) impossible. SCV? Anyways, as I said: Feel free to contribute packaging infrastructure. The means of distribution can still be discussed separately. A lot of things are not available in the "official" Debian/Ubuntu package repositories (Adobe products, Skype, Mendeley, Opera, Steam, …) and still by providing prebuilt packages they are quite easily installable. /Philipp
×
×
  • Create New...