Jump to content

maehne

Members
  • Posts

    336
  • Joined

  • Last visited

  • Days Won

    38

Everything posted by maehne

  1. You seem to use the right approach of using an SC_MODULE to describe the structure of your circuit of ELN primitives. The macros SCA_ELN_MODULE and SCA_TDF_MODULE are exclusively used to define primitive modules in the respective MoCs, which describe the behaviour of the primitive, but not their inner structure. The statement from the SystemC AMS LRM regarding setting the time step refers to the set_timestep() member function, which is offered by all SystemC AMS primitive modules. To keep my models flexible, I tend to prefer to set the time step from the test bench or top level module by calling the set_timestep() member function of one of the accessible primitive AMS modules in that scope, i.e., usually a stimuli source. E.g., if you have instantiated a sca_eln:sca_vsource src1("src1", 2.0); you would call src1.set_timestep(10.0, sc_core::SC_US); to set the time step of the module src1 and the connected ELN cluster to 10 us. I hope that this answers your primary question. I definitely recommend you to read the SystemC AMS User's Guide to get a better insight into the fundamental concepts of SystemC AMS. It is an unfortunate situation that it is currently so hard to find as it is only provided as a bundled download together with the outdated Accellera SystemC AMS 1.0 standard. You can download it from the Accellera's SystemC standards page, where it is listed as "AMS 1.0" in the "Previous releases" section. The statements from this User's Guide are still relevant. It only lacks discussion of the advanced Dynamic TDF modelling features, which were added in SystemC AMS 2.0 and are also part of IEEE Std 1666.1-2016. Unfortunately, efforts to update the user's guide to the current SystemC AMS standard version got stalled due to lack of time of the involved people in the working group.
  2. Thanks for the clarification and feedback on the fix suggested by Philipp!
  3. Dear Guillaume, thanks for reporting this issue! I have forwarded your report to the Language Working Group for further analysis. From a first look, this is indeed a change in behaviour of the SystemC proof-of-concept implementation from version 2.3.1 to 2.3.2. However, it does not seem to touch the standard IEEE Std 1666-2011, as the latter does not mention member function `get_protocol_types()`. Regards, Torsten
  4. As you can see from the DDS block diagram, which you posted, the structure of DDS block is quite simple. I therefore would model it as a single TDF module containing the accumulator register as a state variable. As input, you will have your frequency control and phase offset control signals. The frequency control signal basically is the value, which you continuously add to the value in your accumulator register to generate a periodic sawtooth signal (due to the overflow of the accumulator). The phase offset control signal gets added to the accumulator register to enable shifting the phase of the sawtooth signal. This sawtooth signal is interpreted as the angle operand of a sine function. The period of the sawtooth signal represents a full revolution on the phase circle, i.e., the 2^L possible sawtooth signal values are evenly mapped to phase angles in the range of 0 rad to 2 pi rad (0° to 360°). To avoid repeated calculations of the sine function, the sine amplitudes for all possible angles are pre-calculated and stored in a look-up table (LUT). The current value of the sawtooth signal is then used as the index into that look-up table to find the corresponding output amplitude. To implement this in a generic DDS TDF module, I would choose M, L, and K (bit widths) as generic parameters, which can be passed upon DDS module instantiation to the DDS module's constructor. From M and L, you can calculate the value for the modulo operation, which models in software your overflowing of a M-bits-wide and L-bits-wide addition operation. The difference of M and L gives you the shift distance needed to implement your accumulator output quantisation. The sine LUT needs to have 2^L entries. The sine function should be scaled by 2^(k-1)-1 to use the full range of a k bit wide signed output. All these preparatory calculations, you can do in your DDS module's constructor. The processing function then only needs to only implement the two additions and the amplitude look-up based on the current values of the frequency and phase control inputs and the current value stored in the accumulator register. If you plan to use this kind of module in a model of communication system, you might consider having a look to the Vienna SystemC AMS Building Block Library, which is available for download from systems-ams.org. The latter web site contains also other useful SystemC AMS resources.
  5. Well, you will have to write a test bench, which provides your RC filter with some stimuli for transient simulation or sets up an AC analysis. However, I recommend you to have first a closer look to the fundamental concepts and ideas of SystemC AMS. A good introduction to SystemC AMS is provided by the SystemC AMS extensions User's Guide, which is part of the SystemC AMS extensions 1.0 release. Even though, this discusses only the features available sind SystemC AMS 1.0, it is a good start as SystemC AMS 2.0 and IEEE Std 1666.1 added mainly advanced features related to Dynamic TDF and bug fixes. Also, the SystemC AMS community pages provide some good links to introductory resources to get started with SystemC AMS.
  6. Thanks for providing this feedback on the SystemC PoC implementation! It would help if you could share some more details about the exact error messages as well as a minimal self-contained example exposing the problem you are observing. Then, we may discuss the issue more seriously.
  7. Thanks for reporting this Aarm64-specific issue! I have forwarded it to the Language Working Group's bug tracker so that we can have a look. Support for Aarm64 in SystemC is relatively new. To help localise the source of the problem, could you try whether it helps to configure SystemC to use Pthreads instead of QuickThreads in addition to `--enable-debug --disable-optimize`?
  8. It is up to the IEEE P1666 working group to decide, which currently experimental SystemC API features become official part of a future IEEE Std 1666 revision. The companies/people involved in the maintenance of the SystemC PoC simulator are also actively involved in this standardisation effort. The implementation of experimental features into the PoC implementation serve as a testbed to gain experience with them and collect feedback on their functionality, usability, and usefulness and real world applications. That is important input for the standardisation process.
  9. If it is necessary for you to stick with SystemC 2.3.1, you can simply comment out the offending line in systemc.h. The function is nowhere used inside the proof-of-concept implementation of SystemC.
  10. Yes, this change in behaviour of SystemC 2.3.2 with respect to SystemC 2.3.1 is intentional to better conform to IEEE Std 1666-2011, which states in clause 6.4.4 about signal writes under the SC_MANY_WRITERS policy: This fix by @Philipp A Hartmann is documented in the RELEASENOTES of SystemC 2.3.2:
  11. @David Black: Did you yet find the time to attempt to fix the sem_init issue on macOS?
  12. Thanks Sumit for reporting these issues! I have reported them to the Language Working Group so that we can try to fix them in the proof-of-concept implementation. Regards, Torsten
  13. Regarding sc_simcontext, this class is not part of IEEE Std 1666-2011! It is an implementation artefact, which should not concern you as a user. The proof-of-concept implementation uses it for house-keeping and managing the global state of the simulation kernel.
  14. If you are interested in the elaboration and simulation semantics of SystemC, have a look to clause 4 of IEEE Std 1666-2011. The simulation semantics are based on the discrete-event model of computation and employ the concept of delta cycles to achieve determinism of the simulation results. This is very close to other hardware description languages such as VHDL. Using your favourite search engine, you can find additional information such as the following two tutorials: John Moondanos "SystemC Tutorial" Federico Angiolini "SystemC Tutorial" which give a brief summary of these semantics and the core ideas of SystemC. Though, please take into account that both tutorials are 10+ years old, which means that certain aspects have evolved considerably. For a good introduction to SystemC, I suggest that you read a good book on the topic, such as "SystemC from the Ground Up" by David Black et al. To efficiently use SystemC, you have to master the core concepts of C++ first.
  15. This issue has been fixed in the SystemC 2.3.2 release available from the Accellera website. The function std::gets was definitely removed in the C'11 standard and deprecated in the C++'11 standard so that recent compilers do not provide it anymore as its semantics constitutes a security risk due to buffer overflows.
  16. I am afraid, this is a question, which only @David Black or one of his co-authors of the book can answer. As far as I can remember, I could never find the advertised online material under the URL mentioned in the book. Nevertheless, I still consider it one of the best books on the topic of SystemC.
  17. Thanks for your analysis David! I have reported this issue to the SystemC Language Working Group.
  18. You need to be more precise in your problem description! You did not post the exact error message you might have obtained nor is your code example complete and self-contained. Therefore, any answer by us is mostly based on wild guessing. Please note that you will only actually see traces in your VCD files if actually events happened during your simulation. If your sc_module example constitutes your Design Under Verification, you are missing at least in the posted code snippet some stimuli generator, which would trigger any events. I suggest you that you get familiar with C++ and then start with a good introduction tutorial / book on SystemC before pursuing your own modeling attempts.
  19. Hello Sumit, for compiling SystemC using CMake for C++'17, you will have to specify the C++ language standard version through the variable CMAKE_CXX_STANDARD. The value "17" is only supported since CMake 3.8. If you are still using an older version, this might explain your compilation problems. Enable verbose output for your build system to check which flags are effectively passed to your compiler. Passing the C++ standard version via the "-std=c++17" compiler switch ist more fragile when using CMake, as the latter might add conflicting additional flags. Regards, Torsten
  20. Let me be clear: You don't need to provide -DSCV_DISABLE_USING_NAMESPACES during the compilation of the SCV library itself. You only pass -DSCV_DISABLE_USING_NAMESPACES once you compile your application and link it to the SCV library.
  21. Hello Sumit, Do you mean that you specified -DSCV_DISABLE_USING_NAMESPACES explicitly when compiling the SCV library itself? The preprocessor definition SCV_DISABLE_USING_NAMESPACES is only meant for use in user applications, i.e., you need to pass when compiling your own code. See the RELEASENOTES section 2 for details. When we first prepared the SCV 2.0.1release, we didn't want to import the std namespace by default, but it caused too much trouble with existing code bases, which lead to this ugly method to opt out of it.
  22. First, make sure that you are proficient in C++ as SystemC is a C++ library, which makes extensively use of advanced C++ features! Then, read a good introductory book on SystemC. I am personally not familiar with the SystemC Primer so cannot judge it. I found the book "SystemC from the Ground Up" by David C. Black, Jack Donovan et al. very helpful to learn SystemC.
  23. Newer compiler versions usually are accompanied by a newer implementation of the standard library. This newer version might have been optimised to reduce side-effects when including a standard header, i.e., to only include definitions that are mandated by the standard and to reduce as much as possible the inclusion of other headers, which are only needed for the implementation of its functions. Another thing, which might affect you is that newer compilers might use a newer C++ standard by default, e.g., C++'14 or C++'11. SystemC 2.3.2 already contains functions, which make use of C++'11/14 features. If this is not the default C++ version for your compiler, you must make sure that SystemC AMS and your models get compiled with the same compiler flags, i.e., also against the same C++ version. Regarding your simple SystemC AMS example: You will have to provide more information, i.e., a minimum self-contained code example plus the compiler messages so that we may help you.
  24. The compilation issue, which you describe is not a platform-dependent issue. I guess that you are compiling the SystemC AMS 2.1 PoC against the later released SystemC 2.3.2 PoC implementation. The latter contains many bug fixes and clean-ups, one of which is according to the RELEASENOTES: The memset() and memcpy() are defined in the header <cstring>. This means that the issue can be easily fixed by adding "#include <cstring>" in line 41 of systemc-ams-2.1/src/scams/impl/predefined_moc/tdf/sca_tdf_ct_ltf_nd_proxy.cpp: #include "scams/impl/predefined_moc/tdf/sca_tdf_ct_ltf_nd_proxy.h" #include "scams/impl/core/sca_simcontext.h" #include "scams/impl/solver/util/sparse_library/linear_analog_solver.h" #include <cstring> // needed for memcpy() and memset() namespace sca_tdf { namespace sca_implementation { If you still have compilation errors, add the std:: namespace prefix to the calls of memset() and memcpy(). This issue will go away once COSEDA releases a new version of the SystemC AMS PoC, which does not rely anymore on the implicit inclusion of <cstring>, i.e., has been tested agains SystemC 2.3.2.
  25. As my quotes from the LRM show: It is not forbidden, but strongly discouraged. Therefore, a SystemC implementation may issue a warning if the module hierarchical is not respected, but it is not required to do so. The proof-of-concept implementation of SystemC currently doesn't do this.
×
×
  • Create New...