Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 10/21/2018 in all areas

  1. 2 points
    Hello @kallooran, What version of SystemC library are you using? This issue has been fixed in the release of SystemC-2.3.2. You can find the latest release of SystemC-2.3.3 here: http://accellera.org/downloads/standards/systemc Hope it helps. Regards, Ameya Vikram Singh
  2. 2 points
    David Black

    Seeking Feedback on Datatypes

    Actually, it adds a lot of value. std::array can be passed by reference in a function call and the function can then determine the proper size of the array. This is much better than passing pointers, the C standard. You can also copy an array, which should be synthesizable, which reduces coding and greatly improves readability. It should be possible to implement some #include <algorithm>s on std::array too. Also, you can have bounds checking for additional safety; although, that aspect is probably not synthesizable. Additionally, constexpr should be quite helpful for the synthesis aspect.
  3. 1 point
    AmeyaVS

    What is SystemC library special in?

    Hello @Elvis Shera, It seems your SystemC library has been build with different C++ standard flag. Can you post the output of following commands?: # Compiler version you are using g++ -v # Library Properties: nm -C $SYSTEMC_HOME/lib-linux64/libsystemc.so | grep api_version Regards, Ameya Vikram Singh
  4. 1 point
    Lukas Jakober

    Seeking Feedback on Datatypes

    Some feedback on AC datatypes: We have found AC datatypes to be an invaluable tool for large DSP ASIC designs. My experience is mostly on the simulation front where speed, bit- (but not necessarily cycle-) accuracy, and seamless integration with standard C++ code is important. AC datatypes provide all the relevant digital system design features (clipping/rounding/bit-slicing), as well as support for complex data types, with very little overhead. The ability to customize/expand AC datatype functionality via private headers (for simulation only) is another great benefit that minimizes the need for instrumentation code around HLS code during system simulations.
  5. 1 point
    Eyck

    Read in customized structs

    Where did you check the values of p1 and p2? write() only schedules the values to be written, you will see the actual value in the next delta cycle. Best regards
  6. 1 point
    Roman Popov

    How to connect array of ports?

    Usually you should use sc_vector instead of array. The problem with array is that names of signals and ports in array will be initialized to meaningless values (port_0 ... port_1 ). If you still want to use arrays, then bind with a loop. Here is example, both for array and sc_vector. #include <systemc.h> static const int N_PORTS = 4; struct dut : sc_module { sc_in<int> in_array[N_PORTS]; sc_vector<sc_in<int>> in_vector{"in_vector", N_PORTS}; SC_CTOR(dut) {} }; struct test : sc_module { dut d0{"d0"}; sc_signal<int> sig_array[N_PORTS]; sc_vector<sc_signal<int>> sig_vector{"sig_vector", N_PORTS}; SC_CTOR(test) { for (size_t i = 0; i < N_PORTS; ++i) { d0.in_array[i](sig_array[i]); } d0.in_vector(sig_vector); } };
  7. 1 point
    Thanks guys for the responses. I did not get any detailed information from SELinux where the offending call was made. However, I found it in the QT source in kernel/sc_cor_qt.cpp. Note the PROT_EXEC flag: void sc_cor_qt::stack_protect( bool enable ) { ... // Enable the red zone at the end of the stack so that references within // it will cause an interrupt. if( enable ) { ret = mprotect( redzone, pagesize - 1, PROT_NONE ); } // Revert the red zone to normal memory usage. Try to make it read - write - // execute. If that does not work then settle for read - write else { ret = mprotect( redzone, pagesize - 1, PROT_READ|PROT_WRITE|PROT_EXEC); if ( ret != 0 ) ret = mprotect( redzone, pagesize - 1, PROT_READ | PROT_WRITE ); } sc_assert( ret == 0 ); } I have no clue why this PROT_EXEC is needed at all. Also, the SELinux denial is random because it seems to be memory layout dependent at the time of the call. (It is a pity that the QT source does not include a config section and supporting files for a standalone x86_64 compile and testing.) I will try Philipp's workaround, and will try to reproduce the error. Thanks again, Tibor
  8. 1 point
    Philipp A Hartmann

    tlm_socket_base_if

    Hi Guillaume, I agree, that the new pure-virtual functions in tlm_base_(initiator/target)_socket are not compliant to IEEE 1666-2011. However, I'm curious what use case you have to use these classes directly instead of inheriting from tlm_(initiator/target)_socket, where the functions are implemented? Regarding the implementation on the base socket level, I suggest to add a typedef to the fw/bw interface classes, and use these typedefs in the socket base class then. Something like: template <typename TYPES = tlm_base_protocol_types> class tlm_fw_transport_if // ... { public: typedef TYPES protocol_types; }; // tlm_base_target_socket virtual sc_core::sc_type_index get_protocol_types() const { return typeid(typename FW_IF::protocol_types); } Theoretically, these types could mismatch between FW_IF and BW_IF in manual socket implementations. Therefore, I'd suggest to refer to the FW_IF in the target and BW_IF in the initiator socket. Greetings from Duisburg, Philipp
  9. 1 point
    maehne

    Direct Digital Synthesis

    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.
  10. 1 point
    SystemC is single threaded, you don't need std::mutex. However SystemC does not guarantee any order for processes executed in the same delta cycle. SystemC is a discrete-event simulator, and I suggest you to learn the concepts of simulation semantics from Paragraph 4 "Elaboration and simulation semantics" of IEEE-1666 SystemC standard. The purpose of primitive channels, like sc_signal, is to remove non-determinism by separating channel update request from actual update of value into two different simulation phases. But it only works if there is a single writing process during a delta cycle. In your case if initiator and responder threads are executed on same cycle, they both will read the same "current value" of signal. Initiator will request to set signal value to (valid = 1, ready = 0) and responder will request to set it to (valid = 0, ready = 1). Since there is no guarantee on order between processes, you will either get (1,0) or (0,1) on the next cycle.
  11. 1 point
    maehne

    ELN Low pass filter

    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.
  12. 1 point
    Those questions are covered in detail in paragraphs 14.1 and 14.2 of SystemC standard. Can't answer in a better way. TLM2.0 simulations are not cycle-accurate, so you don't have clock edge events. In AT modeling style you should call wait(delay) after each transport call. In LT modeling style all initiators are temporaly decoupled and can run ahead of simulation time, usually for a globally specified time quantum. For debugging you can use the same techinques as in cycle-accurate modeling: Source-level debugging with breakpoints and stepping Transaction and signal tracing Logging Comparing with RTL, debugging using waveform won't be that effective, because in AT/LT modeling state of model can change significantly in a single simulator/waveform step. Usually preffered way is combination of logging and source-level debug. Debugging TLM models is harder comparing to RTL. Also C++ is much more complex and error-prone comparing to VHDL/Verilog.
×