Philipp A Hartmann

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

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

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

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

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

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)?

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

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

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

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

You need to define the preprocessor symbol "SC_INCLUDE_DYNAMIC_PROCESSES" before including SystemC, when you use the TLM-2.0 convenience sockets. The preferred way to do this is to add it to your compiler command-line switches ("-DSC_INCLUDE_DYNAMIC_PROCESSES"). hth, Philipp

As in the other post about dereferencing NULL pointers, I suspect that (all of?) these reports are false positives as well. If you want to silence the linter about these, just add calls to explicitily non-returning functions like std::terminate. On the other hand, a division by zero will usually abort your simulation as well. ;-) /Philipp

If you look at these parts of the code, you'll see that the pointer is checked for NULL right before. The static analysis tool just doesn't know that SC_REPORT_ERROR does not return (instead, it throws an exception by default). Therefore, all of these can be seen as false positives. /Philipp

You can write a transactor, converting the TLM-2.0 transactions to/from the existing SystemC subsystem interface. /Philipp

As the error says (emphasis mine) you need a default constructor (a constructor without arguments) in your case. In the module, you create an instance of 'decimal' without explicitly initializing it in the constructor of 'seprate_digit'. Theoretically, you could use an initializer list: SC_CTOR (seprate_digit) : in("in"), clk("clk"), d("d") // port names -> recommended practice , decimal(0,0,0,0) // <-- explicitly initialize decimal member Since you use 'decimal' as a signal type, you'll definitely need a default constructor. This could look like the following decimal() /* : dec0(), dec1(), dec2(), dec3() */ // optional, as sc_int has an explicit default constructor {} Secondly, you'll need to define more helper functions to use sc_signal with your own data types, see http://www.doulos.com/knowhow/systemc/faq/#q1 Greetings from Oldenburg, Philipp NB: Why do you post the question three times in 10 minutes? ;-)

Rahul, after fixing the missing '$' at the beginning of your vcd dump, I got the following error on GTKwave: GTKWave Analyzer v3.3.49 (w)1999-2013 BSI Near byte 206, $VAR parse error encountered with 'SystemC.Enable' Near byte 252, $VAR parse error encountered with 'SystemC.output' No symbols in VCD file..nothing to do! As you can see, there is an error in your VCD file (at least according to GTKwave): You use spaces in your signal names. Replace those with '_' or something similar, and your VCD viewer should be happy. hth, Philipp

Sumit, personally I'm indeed interested in proposals towards extended interfaces for extracting information from SystemC simulations. In fact, there is some activity in that area underway, but please don't count on any short-term availability for now. You may be interested in my recent presentation at ESCUG'28. Introspection in general is on the charter of the CCIWG. In this working group, we're currently focusing on configuration first. Some parts may still be needed from the language/kernel side of things, as we currently don't even have a safe, reliable mechanism to extract information during the simulation. Interfaces to provide tracing data to some backends could be improved as well. As Hans already said, commercial tools already provide powerful analysis backends. IMHO, this backend side is out of the scope of standardization. In general, the Accellera SystemC working groups are usually always quite busy and have limited resources to work on all of the interesting improvements that you can think of. On the other hand, with the new SystemC community uploads area here at accellera.org, you can easily share your own experiments and proposals, even without formally joining the Accellera Systems Initiative. Greetings from Oldenburg, Philipp

Yutetsu, thanks for considering to upload the tool to the SystemC community uploads. I didn't check the licensing terms of the upload area before, but when you try to upload files there, you will be asked to confirm the following: As the Apache License less restrictive than the GPLv2 (but still GPLv2 compatible), it's up to you whether you want to your tool available under these terms. Alternatively, you can eventually upload a short technical report, describing the functionaliy of the tool and add an external link to the GitHub repository. Thanks, Philipp

Kocha, this looks like a nice utility and may be useful to the SystemC community in general. Have you considered to upload/share this in the new SystemC community uploads area? Greetings from Oldenburg, Philipp

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

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

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

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

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

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