Jump to content

Philipp A Hartmann

Members
  • Posts

    537
  • Joined

  • Last visited

  • Days Won

    130

Everything posted by Philipp A Hartmann

  1. 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
  2. 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
  3. 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
  4. You can write a transactor, converting the TLM-2.0 transactions to/from the existing SystemC subsystem interface. /Philipp
  5. 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? ;-)
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. Indeed, you're right, Alan. I stand corrected. I apologize for the false allegations. /Philipp
  19. Well, did you actually try to browse the provided website? ;-) http://www.embecosm.com/resources/software//Philipp
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
×
×
  • Create New...