Jump to content

Philipp A Hartmann

  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Philipp A Hartmann

  1. Yes. Have a look at IEEE 1666-2011, Section 4, especially (sc_start, the starvation policy, and sc_pause). ("suspend" and "resume" are functions for individual SystemC processes, sc_start/sc_pause/sc_stop control the overall simulation). /Philipp
  2. The sc_dt::scfx_ieee_float class supports setting the individual parts via member functions as well. Therefore, you can do the bitvector to float conversion by using the following algorithm sketch: Extract the corresponding bits from vector by using the "range()" functions for sign, mantissa and exponent Convert these ranges to integers, e.g. by using the to_(u)int() functions Set the individual parts of an sc_dt::scfx_ieee_float object to these integers Assign/copy the sc_dt::scfx_ieee_float object to a plain float. /Philipp
  3. I've sketched the double to bitvector conversion in an earlier answer already: To do it analogously for 32-bit floats, just use sc_dt::scfx_ieee_float instead of sc_dt::scfx_ieee_double, adjust the sizes of the exponent and mantissa variables according to the 32-bit IEEE 754 representation, and read the mantissa value by a single call to the "mantissa()" function of sc_dt::scfx_ieee_float, instead of the two calls to mantissa0/1. Generally speaking, I would suggest to start with a good C++ book before delving deeper into SystemC. The new one from Bjarne Stroustrup is a very good one for starters. Greetings from Oldenburg, Philipp
  4. Why do you convert the unsigned integer to a string before assigning it to the bitvector? A direct assignment should work just fine. If you indeed need to construct/assign a bitvector from a (C++) string, you need to pass the "C string" representation to the bitvector: in1.to_string(SC_BIN).c_str(); As I said in my answer, there are two bitfield classes available: scfx_ieee_double and scfx_ieee_float. For single precision, use the second one and adjust the sizes of the intermediate variables according to the 32-bit floating point representation. To do this conversion, you need to assign the value to an (unsigned) integer variable in between, as no direct conversion is provided here. Just shift the fractional bits beyond the fixed point and then do an assignment to the bitvector afterwards. sc_unsigned us( fx.wl() ); // temporary unsigned integer variable of appropriate size us = ( fx << (fx.wl()-fx.iwl()) ); // shift to integer bits only sc_bv<32> bv = us; // assign to bitvector See the IEEE Std. 1666-2011 SystemC standard for details on the datatype APIs in SystemC. /Philipp
  5. Your second solution won't work due to the way inheritance works in C++. You would need to use virtual inheritance from all of the interfaces used in sc_fifo_id and sc_fifo. sc_fifo does not use virtual inheritance from the sc_fifo_in/out_if interfaces, which is why you can't "extend" these interfaces and still automatically inherit the implementation from sc_fifo. If you really need the separate interface definitions sc_fifo_id_in/out_if, I would suggest to wrap an sc_fifo instance (in terms of a member object) with your sc_fifo_id class and add forwarding functions to the sc_fifo member to implement the plain FIFO functions. hth, Philipp
  6. char is a datatype to represent a single character. There is the std::string datatype for strings C++, which should be used in SystemC as well. There is no explicit support for these conversions provided by SystemC already. In the proof-of-concept implementation provided by Accellera, there are the (non-standard) classes sc_dt::scfx_ieee_(double/float), which define bitfields for the individual parts of a float or double type. With this, you should be able to do the conversion in terms of a concatenation (beware of endianness). The following is untested: double d = ...; sc_dt::scfx_ieee_double id(d); // convert to IEEE 754 bitfield // prepare parts bool sgn = id.negative(); sc_dt::sc_uint<11> exp = id.exponent(); sc_dt::sc_uint<53> mnt = ( sc_dt::uint64( id.mantissa1() ) << 20 ) | id.mantissa0(); // concatenate parts to bitvector sc_dt::sc_bv<64> bv = ( sgn, exp, mnt ); The reverse conversion is left to the reader. ;-) C++ provides float and double datatypes already. Usually, C++ implementations follow the IEEE 754 representation internally. There is no explicit separate SystemC datatype for IEEE 754 floating point numbers. You can convert sc_fix(ed) numbers via the to_float and to_double member functions. Greetings from Oldenburg, Philipp
  7. In order to give you any suggestions about your "problem", please try to post some more details. What kind of "problem" do you face? What are your compiler errors, if any? Can you post a stripped-down code example, showing the relevant parts of the code (and preferably being self-contained and ready to compile)? One good starting point to learn about defining your own (primitive) channel can be found on the Doulos website. (Season's) Greetings from Oldenburg, Philipp
  8. Bernhard, thanks for the report. I can't confirm this on Linux: $ tar -tzf systemc-2.3.0.tgz | grep req_rsp/tlm_ch systemc-2.3.0/src/tlm_core/tlm_1/tlm_req_rsp/tlm_channels/ systemc-2.3.0/src/tlm_core/tlm_1/tlm_req_rsp/tlm_channels/Makefile.am systemc-2.3.0/src/tlm_core/tlm_1/tlm_req_rsp/tlm_channels/Makefile.in systemc-2.3.0/src/tlm_core/tlm_1/tlm_req_rsp/tlm_channels/tlm_fifo/ systemc-2.3.0/src/tlm_core/tlm_1/tlm_req_rsp/tlm_channels/tlm_req_rsp_channels/ systemc-2.3.0/src/tlm_core/tlm_1/tlm_req_rsp/tlm_channels/tlm_req_rsp_channels/Makefile.am systemc-2.3.0/src/tlm_core/tlm_1/tlm_req_rsp/tlm_channels/tlm_req_rsp_channels/Makefile.in systemc-2.3.0/src/tlm_core/tlm_1/tlm_req_rsp/tlm_channels/tlm_req_rsp_channels/tlm_put_get_imp.h systemc-2.3.0/src/tlm_core/tlm_1/tlm_req_rsp/tlm_channels/tlm_req_rsp_channels/tlm_req_rsp_channels.h systemc-2.3.0/src/tlm_core/tlm_1/tlm_req_rsp/tlm_channels/tlm_fifo/circular_buffer.h systemc-2.3.0/src/tlm_core/tlm_1/tlm_req_rsp/tlm_channels/tlm_fifo/Makefile.am systemc-2.3.0/src/tlm_core/tlm_1/tlm_req_rsp/tlm_channels/tlm_fifo/Makefile.in systemc-2.3.0/src/tlm_core/tlm_1/tlm_req_rsp/tlm_channels/tlm_fifo/tlm_fifo.h systemc-2.3.0/src/tlm_core/tlm_1/tlm_req_rsp/tlm_channels/tlm_fifo/tlm_fifo_peek.h systemc-2.3.0/src/tlm_core/tlm_1/tlm_req_rsp/tlm_channels/tlm_fifo/tlm_fifo_put_get.h systemc-2.3.0/src/tlm_core/tlm_1/tlm_req_rsp/tlm_channels/tlm_fifo/tlm_fifo_resize.h Also on Windows with the 7-zip archiver, the contents are displayed correctly here. Therefore, I assume that WinZip has a problem with such long paths. This is probably due to the fact that the path in question exceeds 99 characters in length, which has been a historical limit in tar archives. Newer tar format variants may not be supported by some versions of tar (or other software used to access the archive, like WinZip in your case). I would suggest to try another archive software, like the aforementioned 7-zip archiver, and check whether it still fails to extract the systemc-2.3.0 archive correctly on your system. Greetings from Oldenburg, Philipp
  9. As I said in my initial answer, the SystemC package already contains quite some starting material in the examples/tlm directory, already available on your computer. ;-) The definite document about SystemC TLM-2.0, including the description of the concepts, terminologies and modeling guidelines is of course the IEEE 1666-2011 standard. You can download the standard free-of-charge (sponsored by the Accellera Systems Initiative) from http://standards.ieee.org/getieee/1666/download/1666-2011.pdf. A very good starting point can be the video tutorials available from the Accellera TLM community pages at http://www.accellera.org/community/systemc/about_systemc_tlm/ All of this should keep you busy for a while. /Philipp
  10. Wrt. TLM-1 vs. TLM-2, these two TLM flavours are both part of the IEEE 1666-2011 SystemC standard. The two flavours implement different modeling styles: TLM-1 is a message-passing based implementation, essentially built around FIFO channels. They can be used in a wide variety of use-cases, including even more abstract models than "just" architecture models with address-based, memory-mapped communication.TLM-2 is an advanced implementation of the "transaction-level modeling" concept, where the payload is no longer passed by-value, but the different "hops" on the transaction path reuse the same object. See the IEEE 1666-2011 SystemC LRM for an in-depth description of the underlying concepts and interfaces.Most widely used within the TLM-2.0 interoperability layer is the TLM-2.0 base protocol. This base protocol defines the payload and communication rules used for the transactions. The tlm_generic_payload is mostly intended for mermory-mapped communication, e.g. bus-based systems./Philipp
  11. John, TLM is a header-only library, there is no need to compile a dedicated TLM library before using the TLM classes in your application. You can find some TLM examples including Visual C++ project files in the 'examples/tlm' sub-directory of the SystemC package. Each example comes with a presentation explaining the contents of the example. Some more information can be found in 'examples/tlm/README.txt' and in the 'docs/tlm' directory. hth, Philipp
  12. Spawning a process without static sensitivity and with dont_initialize set makes no sense. This process will never be activated and will just be an orphaned zombie. What are you trying to achieve? An SC_FORK/SC_JOIN block is meant to spawn a set of parallel (sub-)processes, wait for the completion/termination of all of them, and continue the processing of the spawng process afterwards. Since your spawned process will never complete (since it is never activated in the first place), the SC_JOIN statement will never complete either. Im somewhat doubt that you actually see the "fun" line printed to your output. It should not be printed given my answer above. But your code is not the "real" one anyhow (you're missing some stream operators, for example). Please always try to post the real code. /Philipp
  13. Quoting from IEEE 1666-2011, 5.5.7 (emphasis mine): Since you don't fork anything, on what do you want to join? /Philipp
  14. Mohit, as Ralph correctly pointed out, you should use the correct interfaces in your ports (preferably by using the specialized ports for sc_fifo) and exports: sc_fifo_out< unsigned int > mPort; // Initiator // or: sc_port< sc_fifo_out_if<unsigned int> > mPort; sc_export< sc_fifo_out_if<unsigned int> > mExport; // Target Another addition regarding Ralph's second remark: In general it is indeed good practice to define global preprocessor definitions on the command-line (e.g. from your Makefile) to avoid the problems described by Ralph. For SC_INCLUDE_DYNAMIC_PROCESSES this has indeed been a problem in SystemC 2.2.0. Fortunately, SystemC 2.3.0 is more forgiving and will still include the required dynamic process support at a later inclusion, even if it has been included without an explicit request for it beforehand. Greetings from Oldenburg, Philipp
  15. Julien, in order to give you any reasonable advice to track down the problem, you need to provide additional information about your setup: SystemC version platform, compiler, flags compile/runtime warnings and errors ideally, a code sample to demonstrate the problem Do you still use SystemC 2.2.0? If this is the case, please try to reproduce the problem with 2.3.0. SystemC 2.3.0 should not report "UNKNOWN EXCEPTION" except for exceptions thrown by the user (or third-party libraries) with types not derived from std::exception. This does not happen from within the SystemC library itself. Secondly, sc_core::sc_cor_pkg_qt::abort does not throw any C++ exception on its own. Maybe, there is a destructor throwing from your terminating process? Greetings from Oldenburg, Philipp
  16. Hakim, Well, the reason for this error is the call to "sc_trace" inside your function, i.e. during the simulation. In order to trace the data values, you should add a member variable to your memory and add it to the trace file within the constructor. Something like: SC_MODULE(Memory) { // ... private: ensitlm::data_t data_trace; }; In the constructor, you then register the variable for tracing: Memory::Memory( ... ) : ... { // ... sc_trace(tf, data_trace ,"d"); } And in the "read" function, you update the "data_trace" variable: tlm::tlm_response_status Memory::read(ensitlm::addr_t a, ensitlm::data_t& d) { // instead of "sc_trace(...)" data_trace = d; } Hope that helps, Philipp
  17. Cam, Why do you call the operation "xor reduce"? A bitwise "xor" operation has the same number of bits as its operands. Have you tried the (C++) operator "xor"? unsigned int a = 42; unsigned int b = 21; unsigned int c = (a xor ; // or in short notation (a ^ An "xor reduce" operation as provided by the SystemC datatypes would be defined on a single operand and return a single bit after applying the "xor" bit by bit. This is not defined for the built-in C++ datatypes. hth, Philipp
  18. Alan, Benny, In general, I would not recommend to share data between modules by passing plain references or pointers around. Instead, it should be possible to use the standard semaphore interface in a plain sc_port and bind the semaphore "channel" to it, as you would do with any other channel as well. SC_MODULE(module) { sc_port< sc_semaphore_if > sem_port; // semaphore port // ... // access semaphore functions via "sem_port->", e.g. sem_port->post(); }; sc_semaphore my_sem("my_sem"); module my_module("my_module"); my_module.sem_port( my_sem ); // binding Whether or not a semaphore should be used as a channel across module boundaries is a different question. Greetings from Oldenburg, Philipp
  19. First of all, sc_process_b is not a standardized class, it's implementation specific. Instead, you can use the sc_process_handle class to identify your processes, see IEEE 1666-2011, clause 5.6 for details. The current process handle can be obtained by the function sc_get_current_process_handle: std::cout << sc_core::sc_get_current_process_handle().name() << std::endl; Greetings from Oldenburg, Philipp
  20. See my answer in this thread. Make sure to use proper include guards. This is probably a follow-up error of (1). Greetings from Oldenburg, Philipp
  21. Technically speaking, yes (if you implement some subset, actually used by the convenience sockets). On the other hand, the convenience sockets assume that you actually use the TLM-2.0 base protocol (i.e. the tlm::tlm_base_protocol class) as TYPES parameter. This implies the generic payload. What do you want to achieve? Why can't you stick with the generic payload and use extensions (see 14.2 in the standard)?
  22. Yes, it is possible to use your own payload types. But you don't pass it at the first template parameter to the socket. The first parameter is the BUSWIDTH, which is an integer. Therefore, you get the error about not being allowed to pass a type there. Instead, you need to define your own "protocol traits" and use this instead of tlm::tlm_base_protocol_types: struct my_protocol_types { typedef my_item tlm_payload_type; typedef tlm::tlm_phase tlm_phase_type; }; // ... tlm::tlm_target_socket<32,my_protocol_types> inp_sock; Greetings from Oldenburg, Philipp
  23. Well, your compiler runs out of memory. As it seems that your host may have enough memory, make sure that the user memory limits (ulimit -v -m) are not getting in your way. That said, 100k lines in a single function is quite a lot. We had similar problems with synthesized code at some point in the past and split the results in multiple functions instead. You might want to split your constructor here by creating a set of "init" functions that are called in sequence and put those functions in separate files as well. Greetings from Oldenburg, Philipp
  24. Your SystemC installation is probably incomplete, as the mentioned file should be present in the installed SystemC header tree. Make sure, that the "make install" step has completed without errors. hth, Philipp
  25. The implicit conversion between these types is not possible in all cases, mostly due to the danger of ambiguities in the API. Just add an explicit type conversion instead in terms of a C++ static_cast here: void do_cast(){ castout.write( static_cast<sc_uint<8> >(castin.read() ) ); } Greetings from Oldenburg, Philipp
  • Create New...