Jump to content

maehne

Members
  • Content Count

    315
  • Joined

  • Last visited

  • Days Won

    37

Everything posted by maehne

  1. impulse is a good trace file viewer for visualising the results of simulation runs of SystemC models. "scv" hints that this format is not part of the TLM standard, but part of the SystemC Verification (SCV) library, which you can also download from the Accellera website: http://accellera.org/downloads/standards/systemc The SCV tar ball contains in the docs/ directory several PDF documents, which outline the use of transaction recording. As you can guess from their publication dates in 2003, this mechanism predates TLM-2.0. As I never used that API myself, I cannot provide furth
  2. If you insist to instantiate 16 separate ports to transfer each array element separately from each other, you will also have to write/read the elements in your code one after another using, e.g., a loop over the array. From a simulation point of view, all writes will happen at the same time.
  3. You might find the following thread helpful to address your needs:
  4. The compiler has difficulties to decide which overload of the assignment operator it should use. You can help him by doing a static_cast<bool>(myint[7]).
  5. Signals constitute the communication channels between your models. However, in almost all cases, you should avoid to read/write them directly. Signals are meant to be bound to ports, which constitute the interface of your modules. The read() and write() member functions of the ports are the primary functions to reading a value from the port or writing a value into it, respectively. As you can see from the class definitions of the ports in the SystemC LRM and SystemC AMS LRM, the ports do provide depending on their input/output direction overloads, which allow them to be used in most cases like
  6. As SystemC is just a C++ library, you can pass in and out information to your model by many different means. Command line arguments are just one option. Another simple way is using the standard input, output, and error streams. You can also use sockets and named pipes. The interface to your outside world should be also properly represented in your SystemC model, e.g., by dedicated stimuli and monitor modules, which open up the required communication channels to the outside world and handle then the synchronisation. In its most simple form, you can just use blocking reads and writes to your com
  7. It is hard to guess a reason for the segmentation fault from the information that you provide. Have you tested that your simulation works properly if you convert the time range, which you passed in us/ms/sec to ns? You should also check out the core dump in the debugger. It contains a stack trace so that you can check at which point in the execution the segfault was provoked. Of course, the segfault might have occurred in some internal/standard library function, but in many cases the cause for it happened in user code. Therefore, you will have to step up stack frame per stack frame until
  8. Your point 1) to 4) should typically be implemented in your sc_main(). Note that you can pass into sc_main() command line arguments in the same way as you can do in plain C into main() via the argc and argv parameters. This would allow you to set up your simulation differently according to the passed parameters. Note, you don't need to call sc_main() multiple times to just change the value of a signal. An sc_signal has a write() member function, which you can call from sc_main() to update the signal's value and then continue simulation by calling again sc_start(). However, using this appr
  9. Without a minimal self-contained example exposing your problem, it is hard to give an answer to your question. Did you set besides the data pointer also the data length correctly in your instance of the TLM generic payload? By the way, in C++ and SystemC, you should not use malloc() and free() to allocate/deallocate raw memory, Instead, you should prefer to use an appropriate container or C++'s new/delete operators as a last resort.
  10. Your problem description is a bit contradictory: If you would call your SystemC application as a new process from a really extern C program, there should be no problem as you describe it. However, if you actually mean that you have implemented your own main() function and linked it together with your SystemC application (i.e., sc_main() which instantiates your SystemC model), then you are not allowed to directly call sc_main() from the main() function! Instead, you have to call sc_elab_and_sim(argc, argv) to start elaboration and simulation of your SystemC model. After some preparations, sc_el
  11. For what it is worth, there are several open-source tools developed by academia available, which translate SystemC RTL descriptions to Verilog and vice versa: SC2V: https://opencores.org/project,sc2v GSC: https://opencores.org/project,gsc SysC2Ver: http://sysc2ver.sourceforge.net Verilator: https://www.veripool.org/wiki/verilator Verilog2C++: http://verilog2cpp.sourceforge.net ... and probably others, which can be found through a web search. The development of most of these projects was not very active over the past years, but as they are open-source, you're free
  12. How to initialise your memory content from a file is very HLS tool-specific. Check its documentation! They may or may not support it. Maybe, you'll have to use a specific IP block provided by your tool vendor.
  13. Dynamic memory allocation in behavioural description is indeed not synthesizable, as there is no sensible mapping to digital hardware. You will have to use static memory allocation instead. Check the SystemC Synthesis Subset and the documentation of your HLS toolchain for details on how to write proper synthesizable code in SystemC.
  14. I think you have a misconception about SystemC. It is just a library on top of the C++ language, which helps you to describe the structure and behaviour of your hardware and software system. What will be considered as hardware and what as software depends on the language elements you use: An SC_MODULE with ports will or sockets will be considered as hardware due to the semantics associated to the used classes. A header or CPP file as well as as generic functions, classes, or structs do not have any particular semantic attached to it, which would qualify them from the beginning as hardware. The
  15. Thanks for the background information on your use case. Your justification for using sc_uint_base is sound for me.
  16. By the way, Visual Studio 2013 already has some support for C++'11 including Lambdas: https://msdn.microsoft.com/en-us/library/hh567368.aspx
  17. You can find the requested example in the above cited clause 5.5.6 of IEEE Std 1666-2011.
  18. You can use sc_bind() for this purpose, which is described in clause 5.5.6 of IEEE Std 1666-2011. Though, you might need to use sc_spawn instead of SC_THREAD to register your process with the SystemC kernel. If your compiler supports C++'11, you can also use a Lambda function instead of sc_bind(). Cf. to the Doulos white paper "What C++11 means to SystemC?" by David C. Black for details.
  19. You can use sc_bind() for this purpose, which is described in clause 5.5.6 of IEEE Std 1666-2011. Though, you might need to use sc_spawn instead of SC_THREAD to register your process with the SystemC kernel. If your compiler supports C++'11, you can also use a Lambda function instead of sc_bind(). Cf. to the Doulos white paper "What C++11 means to SystemC?" by David C. Black for details.
  20. I don't see any issue from the point of the LRM. From a methodology perspective, I think it depends on the abstraction level and use case you are targeting. On the side of modules representing actual hardware, I would probably prefer to have a port type stating clearly the width to have the compiler statically check for me the correct binding of ports and interfaces. For stimuli generators and monitors, a more generic base type is OK for me. Where it then interfaces with HW modules, I would insert a small adaptor. You may also consider to have a channel, which can bind to sc_int<W> and s
  21. Your Qt5 GUI and the SystemC model should run in separate threads. Access to shared state will have to be protected using the appropriate synchronisation primitives of your threading library. IEEE Std 1666-2011 provides some facilities to control the execution of a SystemC model, see, e.g., this nice presentation by John Ainsley at DATE 2012 on the "IEEE Std 1666-2011: The New SystemC Standard" from slide 17 onwards. The presentation also explains how to implement interactions between SystemC and OS threads using async_request_update() (slide 36 and onwards). There was also an interesting disc
  22. Some comments to your code snippets: Prefer to #include "systemc" instead of "systemc.h" to avoid namespace pollution. You'll then have to prefix SystemC symbols with the appropriate namespace prefix (recommended in most cases, especially headers). In the context of functions and implementation files, you can selectively import symbols from the SystemC namespaces with appropriate using statements. Consider also to put your own classes, functions, typedefs and other declarations and definitions in a dedicated namespace to facilitate future code reuse! #include "iomanip" ->
  23. From a quick glance into your source files, I see: Your headers are missing #include guards. You don't include SPPS.h in your header SPPS48.h, but your members M1, M2, and M3 are of type SPPS, which you define in SPPS.h I recommend that you don't use the header <systemc.h>, as it seriously pollutes your public namespace. Use header <systemc> instead and import only the symbols in your current namespace, which you actually use. Your constructor allocates manually memory for the members M1, M2, and M3 using "new", but lacks a destructor, which would release th
  24. Alan's code snippet already shows you how to write constructors with additional arguments. The only thing, which is omitted in the snippet, but mentioned in his post is the necessary call to the SC_HAS_PROCESS macro with the name of the module class as argument so that you can use SC_THREADs and SC_METHODs in your module. I tend to write it just in front of the declaration of the first constructor. Thus, Alan's example would look like: #include "systemc.h" SC_MODULE(mod) { int i; SC_HAS_PROCESS(mod) mod(sc_module_name nm) : sc_module(nm) { // ... } mod(sc_module_
  25. I totally agree with David, a good read for an introduction on SystemC is, e.g., "SystemC from the Ground Up" by David Black and Jack Donovan.
×
×
  • Create New...