Jump to content

Philipp A Hartmann

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Philipp A Hartmann

  1. 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
  2. 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
  3. 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
  4. Quoting from IEEE 1666-2011, 5.5.7 (emphasis mine): Since you don't fork anything, on what do you want to join? /Philipp
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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)?
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. You can write a transactor, converting the TLM-2.0 transactions to/from the existing SystemC subsystem interface. /Philipp
  21. 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? ;-)
  22. 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
  23. 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
  24. 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
  25. 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
  • Create New...