Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 12/18/2019 in all areas

  1. 2 points
    The Accellera SystemC AMS Working Group released the 2020 edition of the SystemC AMS User's Guide. You will find the user's guide on this page: https://www.accellera.org/downloads/standards/systemc This version of the user's guide is fully compatible with the SystemC AMS standard released as IEEE Std. 1666.1-2016. It describes all the features introduced in the SystemC AMS language standard during the last decade. For example, the user’s guide now explains the use of the dynamic timed data flow capabilities, to make AMS system simulations even more efficient and running even faster. The SystemC AMS Working Group is currently preparing the release of the user's guide application examples as separate download. Availability of these application examples will be communicated at a later stage. Please use this forum to post your questions or remarks on the user's guide.
  2. 1 point
    I believe the original intent was to be able attach "attributes" in the general sense to modules, channels, ports, processes and other "objects", which could be used for unforeseen or unaddressed needs in the future. For instance, if you wanted to add power information to certain modules (e.g. static leakage), and then add some type of processing to analyze power consumption either dynamically or later. This has been used internally at a few companies and I hope the feature will stick around. Although, the CCI (Control, Configuration & Inspection) WG (Working Group) of Accellera may argue their "configuration" solution may better address these ideas. [Personally, I have not seen the current CCI solution to work on all platforms yet (implementation needs more work) and the documentation needs more work. I think there are some issues with the version of SystemC and C++ compiler features.] You download/install/test CCI from https://accellera.org/downloads/standards/systemc .
  3. 1 point
    David Black

    SC_CTHREAD slows down simulation

    You are missing at minimum a single wait() in the infinite loop. SystemC is an event driven simulator and as such concurrency is modeled using co-operative multi-tasking. An infinite loop is an infinite loop. No pre-emption.
  4. 1 point
    Anton

    SystemC-AMS learning resources/examples

    Hi guys, I've recently started learning SystemC-AMS, just for fun mainly. On my learning path I've figured out that: There is no any good text book on SystemC-AMS available (except of SystemC and SystemC-AMS in Practice: SystemC 2.3, 2.2 and SystemC-AMS 1.0, which doesn't seems to be good neither according to customers review with overall grade 1 out of 5) There are few examples on the web available, so it's hard to learn by reviewing what other people are doing There are few educational resources available, probably the most useful (at least for me) was SystemC AMS Extensions User’s Guide (dated 2010-03-08), which seems to be outdated (for instance it mentions usage of set_timeoffset() member function which is deprecated in SystemC AMS 2.0 Analog/Mixed-signal (AMS) Language Reference Manual (dated 2016-08-12)). In some other posts on this forum I saw @Martin Barnasconi mentioning that UM is presently being updated by the committee. While googling you can find a bunch of scientific/research papers and presentations on the topic, but a holistic examples are rarely given, most often just code snippets are present. In this post I'd like to share an SystemC-AMS implementation of Algorithmic (Cyclic) ADC. The example uses TDF and DE domains showcasing the aspects of TDF<->DE domain crossing discussed in the SystemC AMS Extensions User’s Guide. It can be found here. Being a Simulink user I was wondering about simulation performance improvement the SystemC-AMS gives. Some scientific papers I was able to find touching this topic reported 5-10 times improvement. For this example of Algorithmic ADC implementation also a Simulink model was created (located in same repository here). Relevant modelling techniques was used in both SystemC-AMS and Simulink models, so the comparison is pretty much an apple-to-apple. It can be seen by running both models that SystemC-AMS model gives around 20x simulation time improvement over Simulink model. The Simulink simulates 11*2048 cycles in about 1.5 seconds, while SystemC-AMS simulates same amount of cycles in just 0.067 seconds. That is remarkable improvement of simulation speed. I hope this post will be helpful for others who learn SystemC-AMS. Please feel free to comment to this post with useful materials/examples to help others on their learning way. I'd love to hear if you guys knows other great resources that helped you. Thanks.
  5. 1 point
    David Black

    SYNTHESIZABLE SystemC

    sc_core::sc_signal<sc_dt::sc_bv<32> > register[32]; ... SC_METHOD(prc_assign_rf_reg); for(int i=0;i<32;++i) { sensitive << register[i]; } Above should work from a simulation point of view, but probably fails the synthesizable test. Tools might support it. Unfortunately, despite the existence of a Synthesizable subset standard, you are really at the mercy of each implementation vendor since they usually vary from the standard in various ways. The standard simply provides a starting point they attempt to match, but then add their own extensions and/or exceptions. RTFM. If they ever get around to doing modern C++, they could easily enough implement C++11's std::array container, which is conceptually very synthesizable. Then you could possibly even do: #if __cplusplus < 201103L #error Requires C++11 or better #endif #include<array> std::array<sc_core::sc_signal<sc_dt::sc_bv<32>>,32> register; ... SC_METHOD(prc_assign_rf_reg); for(const auto& reg: register) sensitive << reg; // or possibly with changes to synthesizability rules sensitive << register;
  6. 1 point
    Thanks for reporting this issue! I think your use case is justified. However, the decision to not installing the header seems to have been made on purpose as utils/sc_stop_here.h is explicitly added to NO_H_FILES in src/sysc/utils/files.am. The behavioural difference between the Automake and CMake-based build flow is probably unintentional. I have reported the issue to the LWG for investigation.
  7. 1 point
    Timur Kelin

    Implement sc_trace for std::string

    The basic idea: calculate hash for the string call sc_trace for the hash value update a translation file which maps hash values and the string contents. Exemplar github project which utilizes this approach: https://github.com/timurkelin/simschd In this project the translation file is written before the simulation starts raw 64-bit hash values: simvision mmap translation applied: simvision mmap is generated automatically and translates string hash (%x=) into string value (-label {}). mmap new -reuse -name schd -radix %x -contents { {%x=0000000000000000 -label { } -bgcolor #000000 -font -*-courier-medium-i-normal--12-* -shape z -textcolor #F8F8FF -linecolor green} {%x=613d30040ed92e78 -label {delay_chain.dly10} -bgcolor #000000 -font -*-courier-medium-i-normal--12-* -shape bus -textcolor #F8F8FF -linecolor green} {%x=d1a020f2dd73715f -label {delay_chain.dly10} -bgcolor #000000 -font -*-courier-medium-i-normal--12-* -shape bus -textcolor #F8F8FF -linecolor green} {%x=69071983ebd1b6d4 -label {delay_chain.dly10} -bgcolor #000000 -font -*-courier-medium-i-normal--12-* -shape bus -textcolor #F8F8FF -linecolor green} {%x=3a5413510c68f021 -label {run_80.exec_80()} -bgcolor #808000 -font -*-courier-medium-i-normal--12-* -shape bus -textcolor #F8F8FF -linecolor green} {%x=55691ef70e86d835 -label {run_60.exec_60()} -bgcolor #8b0000 -font -*-courier-medium-i-normal--12-* -shape bus -textcolor #F8F8FF -linecolor green} {%x=6f9e19f9823cb15c -label {run_40.exec_40()} -bgcolor #4b0082 -font -*-courier-medium-i-normal--12-* -shape bus -textcolor #F8F8FF -linecolor green} } generated gtkwave translation file for the similar appearance 0000000000000000 ?grey0? 613d30040ed92e78 ?grey0?delay_chain.dly10 d1a020f2dd73715f ?grey0?delay_chain.dly10 69071983ebd1b6d4 ?grey0?delay_chain.dly10 3a5413510c68f021 ?OliveDrab?run_80.exec_80() 55691ef70e86d835 ?DarkRed?run_60.exec_60() 6f9e19f9823cb15c ?navy blue?run_40.exec_40()
  8. 1 point
    Eyck

    HERITAGE on a SC_MODULE with THREAD

    You are defining a thread in ahb_master and a thread in dummy_master where both have the same name (tick) but a different C++ signature (ahb_master::tick and dummy_master::tick). Actually defining the tick thread in ahb_master doesnt make any sense, moreover since it doesn't do anything it will be declared immediately after simulation start. BR
  9. 1 point
    This compiler warning is a false positive. There is a loop in sc_fifo<T>::read(T&) ensuring that the fifo is not empty (and the success of the nb_read(T&) is even guarded by an sc_assert😞 while( num_available() == 0 ) { sc_core::wait( m_data_written_event ); } bool read_success = sc_fifo<T>::nb_read(val_); sc_assert( read_success ); The check for num_available() is even stricter than the check in buf_read, but I can imagine that some compilers might not be able to prove this invariant. Therefore, unconditionally initializing the local variable to silence the warning might be an acceptable trade-off.
×
×
  • Create New...