Jump to content

Philipp A Hartmann

Members
  • Content Count

    534
  • Joined

  • Last visited

  • Days Won

    129

Everything posted by Philipp A Hartmann

  1. The templated SystemC datatypes all build upon a "dynamic bitwidth" implementation (e.g. sc_uint_base) that has its bitwidth set upon construction. The templates themselves only provide constructors (initializing the length of the base class), assignment operators, and related functions. It would of course be possible to add a static member to the sc_(big)(u)int templates to provide direct access to the template argument: template< int W > class sc_int : public sc_int_base { static const int static_length = W; // or some other name // ... }; For these classes, an external helper can be defined easily as well: template< typename T > struct number_traits; // undefined by default // specialization for SystemC integer datatypes template< int W > struct number_traits< sc_dt::sc_int<W> > { static const int length = W; }; // same for sc_uint, sc_bigint, ... But for true generic programming, the concatenation and range classes would require additional meta programming to make this fully usable. Secondly, as the base classes should provide access to the length() of the instances as well, this function would require to be declared virtual (as the base classes are non-templated). This would increase the size (and eventually the runtime cost) again. That said, if you're interested in bit true datatypes implemented with fully deduced widths etc., you might want to use the Mentor/Calypto "Algorithmic C datatypes", see http://calypto.com/en/products/catapult/overview/. Greetings from Oldenburg, Philipp
  2. Of course you can use members of your class without inheriting from their type. Otherwise, C++ would be an even stranger language than it is already, wouldnt it? Assuming that you do more than just forwarding the dut_input to the sc_output (by calling the write function) in your implementation, yes this can be seen as the right way. Indirectly, yes. You can bind the dut_input either to a port or to another export. As your class claimed to be "both", the compiler can't tell which bind function to call. /Philipp
  3. Why does your "eq_wrapper_top" inherit from an interface and a port? Maybe, you probably just want to drop the tlm_analysis_port<eq_transaction> base class. Or why do you need it? hth, Philipp
  4. Looking at the output of your 2.3.1 build, something is seriously wrong here: vahdaneh@vahdaneh-SVT14126CXS:~/Desktop/systemc-2.3.1/objdir$ make /bin/bash: -c: line 0: syntax error near unexpected token `do' /bin/bash: -c: line 0: `fail= failcom='exit 1'; forf in x $MAKEEFLAGS; do case f in *=* -- [!kk]*);; *k*) failcomm='fail=yes';; esac; don;\ o_seenn=no; taget=`eccho aall-recursive | sed s/- recursive/; list='docs src examples''; for subdir in $$llist; do echo "aking $$target in $subdir"; f test "$subddir" = "."; then \ dot_seen=yes; local_tagett="$targett-am"; else \ loccal_targget="$target"; i; (CDPAATH=${ZSSH_VERSIO+}:" && cd $suubdir && make $local_target) ||eval $faillcom ' make: *** [all-recursive] Error 1 There are a many (randomly) duplicated characters in the command, and sometimes letters are missing. It seems that your configure call failed to generate working Makefiles. This is quite strange, and I have not seen this effect before. Maybe it is indeed related to broken line endings. /Philipp
  5. Oh, and I should have said: Please use "make V=1" and post the full command, make is failing to run.
  6. No, unfortunately, there is no API to determine which events have fired and triggered the execution of a given process. You need to add additional information to your system, e.g. by storing the value of sc_delta_count for each event notification and check its value in the triggered process (which is how the event() method of sc_signal works internally). Immediate notifications are even more difficult to track reliably. Yes, the method would be evaluated once, even if multiple events from the sensitivity list fired in the same update phase (notify(SC_ZERO_TIME);). So this could be an appropriate modeling style. Again, immediate notifications are more difficult to handle reliably: Here, the method may be triggered twice in the same evaluation phase, depending on the (implementation-defined) order of evaluation of runnable processes. hth, Philipp
  7. First of all, you should use SystemC 2.3.1, released a couple of months ago. Secondly, according to the information you provide, your setup should work right out of the box. Can you post the full output of your configure and make calls? Additionally, please post the output of your environment variables, e.g. from the command env. From the error message, it seems you may be having a stray semicolon in e.g. your CXXFLAGS variable, leading to the breakage of the compiler call (then suddenly beginning with "-c"). But it's hard to tell without more information… hth, Philipp
  8. Yes, running multiple evaluation phases (sequentially and/or concurrently/interleaved) is not mandated by the standard, see e.g. 4.3.2: If you have separated the use of the different simcontexts properly, this may work with the current proof-of-concept implementation. If you intend to run these simulations concurrently, it will most probably fail due to the current non-reentrancy of some parts of the kernel (and the datatypes). In case you need communication between the models, it will be even more complicated. Still, there are other parts of the simulator state, which are currently not fully encapsulated by the/an explicit simcontext. You may see strange artefacts and interferences between the simulations, especially in some corner cases. Also the reporting mechanism is not routed through the simcontext. There is work ongoing in the LWG to address that topic, although I can't promise any timeline or "standardized API" around this feature request. It will probably stay implementation-defined in IEEE 1666. As said above, the non-standard function name is likely the least of your problems. ;-) I agree that there are several use cases for that and it has been discussed in the past multiple times. I don't see a way to reduce the "risk of not being compatible with upcoming versions of SystemC" from the user perspective. You are of course welcome to join the Accellera Systems Initiative and actively contribute towards a solution for this in the LWG. Greetings from Oldenburg, Philipp
  9. This is not true. The OS scheduler has nothing to do with the SystemC process scheduler, see my recent answer here. /Philipp
  10. The OS scheduler has nothing to do with the SystemC process scheduler. SystemC uses a custom, cooperative scheduler following the simulation semantics as defined in IEEE 1666-2011: Only one SystemC process is guaranteed to run at all times. Even if SystemC processes might be implemented as OS threads, their scheduling is enforced to follow the SystemC rules. You can't tell. All of them are "equal". Whether or not this is sufficient for the original poster's use case depends on his/her requirements. /Philipp
  11. The same would be the case for a plain C assert: #include <cassert> #define NDEBUG int main() { assert( false ); } I'll leave the solution as an exercise for the reader. ;-) (Hint: look for the word "before" in the link above.) /Philipp
  12. Yes, defining NDEBUG also disables the sc_assert statements in the SystemC proof-of-concept implementation. Having said that, I don't think it is a good idea to do so globally. You usually want your simulation to reliably abort in case of an error/bug, instead of running into arbitrary undefined behaviour. I would recommend to leave assertions active by default until profiling proves that (specific) assertions have a significant performance impact. In such cases, selectively disable only these assertions in optimized configurations. /Philipp
  13. First of all, it somewhat depends on the preemption scheme you need to support. Are the serial threads preemptible while running one of their phases? If not (and it looks like this in your description), you can refactor the model to only use M "real" SystemC threads, one for each parallel thread. The serial threads would then have an explicit "state" (i.e. the functional state and the phase they're) and the phases could be implemented as individual functions. When a serial thread is resumed, you can simply call the corresponding phase function from its assigned "parallel thread". Details left to the reader. ;-) hth, Philipp
  14. You can query the event() function of the signal, to check whether it has been triggered in the previous update phase (see IEEE 1666-2011, 6.4.9). Of course, multiple signals might have been updated even though your process is only invoked once. Greetings from Oldenburg, Philipp
  15. No. The evaluation order of runnable processes is implementation-defined in SystemC, see IEEE 1666-2011, 4.2.1.2. There is no (standardized) backdoor API to influence the process scheduling of the kernel. Of course, you can add additional layers of scheduling on top of the SystemC scheduler, e.g. by defining your process dependencies and notifying properly crafted sc_events to trigger the successor process(es). Another option might be to model the system with the SystemC AMS extensions, which provides the timed dataflow (TDF) model of computation. But this somewhat depends on the real requirements. Additionally, the resulting TDF schedule can only be implicitly defined by constraining the scheduler in terms of process dependencies (AFAIK). Greetings from Oldenburg, Philipp
  16. You could try to print the return value of the pthread_create call via strerror (untested): int notok = pthread_create( &cor_p->m_thread, &attr, &sc_cor_pthread::invoke_module_method, (void*)cor_p ); if ( notok ) { std::fprintf(stderr, "ERROR - could not create thread: %s\n", strerror(notok) ); } You either set a too small stack size (EINVAL), or are running out of resources (number of allowed threads, memory limits) (EAGAIN). You may need to rethink your modeling approach, given the huge number of processes you have. Before reinstalling your OS, you can try to use a MinGW compiler, as mentioned in my previous answer. If you run configure from within your Cygwin environment, specify the MinGW target and the MinGW compiler on the command-line: ../configure --target=i686-pc-mingw32 CXX=/path/to/mingw32/g++.exe Because performance-wise, Cygwin with Pthreads is probably the worst combination on Windows platforms. hth, Philipp
  17. There is indeed an issue in the Makefile.rules file, used when compiling the examples manually. Due to some incomplete try to stay backwards-compatible with the old TLM Makefiles (which used CC instead of CXX), the Makefiles prefer CC over CXX (even for the linking) if explicitly set by the user. You should be able to fix the problem by changing all occurrences of $(CC) to $(CXX) in both examples/sysc/Makefile.rules and examples/tlm/build-unix/Makefile.rules. I'll queue up this change for a future release of the proof-of-concept simulator. Thanks for reporting, Philipp
  18. I think it would be fairly straight-forward to add an sc_event_or_list overload to set_sensitivity, as it would just be expanded and appended to the set of events the process is statically sensitive to. For symmetry reasons, users would certainly want to have an sc_event_and_list overload as well, but this "mixed expression" sensitivity is currently not easy to add (e.g. to the proof-of-concept implementation) and nobody cared enough to propose an implementation. I agree that in your case there is some additional burden to work around this limitation. /Philipp
  19. Sure, set_sensitivity can be called after the start of the simulation. And yes, there are no overloads to use sc_event_and/or_lists for static sensitivity, mostly for historical reasons (and limitations in some implementations). But why not simply use them with dynamic sensitivity? Simply store (a copy of) the event list in your module and use wait( event_list ) instead of a plain wait() inside your spawned process. hth, Philipp
  20. Oh, I should have mentioned that you can try to build your SystemC kernel with a Pthread threading implementation: ../configure [...] --enable-pthreads The stack size requirements might be different there. Alternatively, you can use a MinGW32 compiler (http://mingw-w64.sourceforge.net/), which then uses the native Windows threading facilities (WinFiber) under the hood. hth, Philipp
  21. Short answer: You can't. The current proof-of-concept simulator employs a stack protection mechanism to detect stack overflows by using the OSs memory protection mechanisms. This requires an additional memory page (as a red zone) after the "real" stack. As you have seen, this requires the minimum stack size to exceed a certain value. 0x1000 is certainly too small here. I would have expected that 0x10000 could work, but this seems not to be the case. If your threads are so small and simple, maybe you can port them to SC_METHODs. Alternatively, you can try to switch to a 64-bit OS. /Philipp
  22. No. In SystemC 2.3.1, the platform-specific defaults are defined in sc_thread_process.h. To obtain the default value used on your platform, you can query the SC_DEFAULT_STACK_SIZE constant in your application. Use sc_spawn_options, see Section 5.5 in IEEE 1666-2011: sc_spawn_options opt; opt.set_stack_size(0x10000); sc_spawn( func, "func", &opt ); Yes, on 32-bit OSs, the overall memory space for user applications is usually limited to 2GB (on Windows) and 3GB (on Linux). On 64-bit OSs, this limitation is lifted. hth, Philipp
  23. In general, it is not different from a classical C++ shared library. The details can't be answered without a more detailed question and/or problem description. If your "SystemC program" contains an sc_main, you can afterwards call "sc_elab_and_sim" from your scripting language to setup the kernel and the simulation model. See Section 4.3.2 in the IEEE 1666-2011 standard. hth, Philipp
  24. The file visualc.hpp is part of the external Boost library, where a rather old version is partially packaged with SystemC. The documentation in the README file is correct. You can safely ignore the warning during the build. The version check inconsistency has been fixed in SystemC 2.3.1 (among many other things). I would encourage you to update to the latest version. Greetings from Oldenburg, Philipp
  25. With the plain socket (interfaces), there is no way to determine the socket through which an interface function has been called. There are so called "tagged" convenience sockets provided as part of the TLM utilities (see IEEE 1666-2011, Section 16.1.3, including an example at the end of the section). This topic has been discussed here recently in this thread. hth, Philipp
×
×
  • Create New...