Jump to content

Philipp A Hartmann

Members
  • Content Count

    524
  • Joined

  • Last visited

  • Days Won

    126

Everything posted by Philipp A Hartmann

  1. First of all: Yes, if you use MSVC 2010, you should rename/copy the msvc80 directory to msvc10 to allow enable the correct lookup of the SystemC.lib. But you currently don't come to this point. From the error message, it looks like you have the MSVC executable listed after the Cygwin command-line tools in your PATH environment variable. Obviously, the Cygwin link.exe doesn't understand the options of the MSVC LINK.exe. hth, Philipp PS: You should use SystemC 2.3.1 to avoid the warning about the unsupported compiler version. Secondly, a number of bugs have been fixed in this release.
  2. Well, but you tried to add these "members" from Python during the construction phase afterwards. /Philipp
  3. Quoting my earlier reply (emphasis added): "Otherwise, you can create a wrapper (or a derived class), with no own sc_object/sc_module members and construct the real SystemC module from within C++." The module/object hierarchy creation is closely related to the sc_module_name stack. Once the sc_module_name instance is destroyed (after the completion of your ExampleModule (base class) constructor), the "current module" is removed from this stack. Therefore, the ports you create afterwards can not be assigned to the correct module. Again, a workaround may be to create the ports via Python from within before_end_of_elaboration callback, where the module hierarchy is correctly restored without having a proper sc_module_name stack. The deprecated constructor comes from very old versions of SystemC (before the introduction of sc_module_name) and requires you to manually call the (similarly non-standard) function end_module after the creation of all sc_object members at the end of the constructor. Otherwise, your hierarchy will be messed up in case of multiple (nested) modules. I would not recommend this approach. Greetings from Oldenburg, Philipp
  4. As said before, you have to have an sc_module_name parameter in the (leaf) constructor of your module class hierarchy. Using the deprecated constructor will likely mess up your object hierarchy during elaboration. You can directly call such a constructor with a const char* argument, as you can implicitly construct an sc_module_name from a const char*. Maybe this is all you need. Otherwise, you can create a wrapper (or a derived class), with no own sc_object/sc_module members and construct the real SystemC module from within C++. hth, Philipp
  5. In your case, the Timer module (or a dedicated interrupt controller, wherever your "interrupt clear register" is located) would be responsible for actually writing to the interrupt signal. This can then be locally resolved to a single control process within the module. However, especially for interrupt signals, SC_MANY_WRITERS is a common use model. Note that SC_MANY_WRITERS is perfectly safe to use, because you are still not allowed to write to a signal from multiple processes in the same delta cycle (as that could lead to non-deterministic behaviour). /Philipp
  6. You can't let the second process write to the same signal (deassert) without using SC_MANY_WRITERS. (This wouldn't make much sense in real HW without additional logic either.) Solution: Restructure your design to have a single writer to each signal instead. Hard to be more specific with the available details. hth, Philipp
  7. Yes, the segmentation fault is caused by trying to access the terminated process instance (to format the error message), which has been deleted already. This problem will be fixed in the next public release of the Accellera proof-of-concept implementation. Thanks for your report, Philipp
  8. Why can't you just use a tlm_fifo instead, which already provides peek/poke? /Philipp
  9. Strictly speaking, it is your fault. Quoting 1666-2011, section 5.2.3 (sc_module, constraints on usage), emphasis mine: So the last variant posted by Ralph is the correct definition. /Philipp
  10. The events of an sc_signal are triggered during the update phase of the simulation. Therefore, you can't cancel the event from a SystemC process. What are you trying to achieve? Why are you sensitive to an sc_signal event, if you don't want to be triggered?
  11. You try to create a primitive channel (sc_signal, sc_fifo, ...) during the simulation. This is not allowed in SystemC. You have to create all of these channels during elaboration (i.e. before the simulation is started). hth, Philipp
  12. In SystemC, you can't partially change the (new) value of a signal. Instead, you can simply use a local temporary variable: sc_signal<des_struct> xyz,abc; des_struct tmp = xyz.read(); tmp.attrib = 4; abc.write(tmp); If you want to keep things in a single line, add a setter with a "fluent API" (i.e. returning the object itself) to the des_struct: class des_struct { public: // ... des_struct& set_attrib(uint16_t a) { attrib = a; return *this; } }; // allows: abc.write( des_struct(xyz.read()).set_attrib(4) ); hth, Philipp
  13. In general, it's perfectly fine to use sc_signal with a custom data type, provided that you have a properly defined comparison operator (and an sc_trace overload). In your case, I think your comparison operator is broken: In the code above, you update "end" with a != expression. This seems to be strange. Shouldn't this be ==? hth, Philipp
  14. It's documented in the IEEE Std. 1666-2011, downloadable at no cost at http://standards.ieee.org/getieee/1666/download/1666-2011.pdf (including SystemC and TLM-2.0). Greetings from Oldenburg, Philipp
  15. 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
  16. 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
  17. 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
  18. 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
  19. Oh, and I should have said: Please use "make V=1" and post the full command, make is failing to run.
  20. 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
  21. 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
  22. 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
  23. This is not true. The OS scheduler has nothing to do with the SystemC process scheduler, see my recent answer here. /Philipp
  24. 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
×
×
  • Create New...