maehne

Thanks for your suggestions, I reported them to the SystemC Language Working Group.

The group of Daniel Große from University of Bremen and now Johannes Kepler University in Linz has released a RISC-V-based virtual prototype under MIT license, which could be of interest for you.

You should not edit the configure file directly, but rather the file configure.ac. After that, you'll have to run the config/bootstrap to regenerate the build system. For this to work, you'll have to install GNU libtool, GNU automake, and GNU autoconf, e.g., through MacPorts.

If you want to set the initial value of the signal to which the port int_o will be bound during elaboration, you can use the member function initialize() (cf. to clause 6.10.4 of IEEE Std 1666-2011).

Thanks @William Lock, for sharing your experience of building SystemC on macOS for the Apple M1 architecture. I opened an issue on the LWG’s internal tracker to update our build scripts so that it will work out of the box in the future.

If you add the wait() into the inner for loop, the algorithm will be implemented using a FSMD architecture. Each sample will then take 4 clock cycles to get processed. A new sample is processed only every 4 clock cycles as well. If you want your algorithm to be pipelined, your loop needs to get unrolled. Depending on your HLS tool and your coding style, the synthesizer might automatically defer the pipeline, require some hint in form of a pragma or you’ll have to rewrite your model. Similar to classic HDLs, it helps to first imagine the structure and behaviour of the hardware, you want to implement and then try to express it in code following the recommended coding styles of your tool. A for loop with a fixed number of iterations can behave like a for generate statement in VHDL. Then, i can be simply of type int, because it is just an index and not a transient value kept in a register.

Your code snippet of the tx_top::process() confirms that it gets activated once per rising edge of clock and then waits until the next rising edge of clock. All code, which gets executed in your while loop (including the function calls gets executed in the same delta cycle. It's important to be aware that tracing of signals and variables happens not upon assignment to them, but as part of the simulation cycle, i.e., a new trace value gets only recorded once there are no new events to process for the current time (because all signals have stabilised). After that, the simulator advances time to the next moment when an event occurs. This explains, why you are observing in your VCD trace only the final values of your traced internal variables from the end of your function executions. So, @AmeyaVS's hypothesis in his first reply was right to the point! If you want to trace your algorithm execution within a delta cycle, you are on your own. One option is to set a breakpoint on the respective function and step through it while monitoring the evolution of the variable values. Another option is to output the values at strategic points in your code to some output stream.

A running simulation is no indication that you model follows established SystemC coding practices. The suggestions by @AmeyaVS are all valid. The code snippets, which you provided use for the moment only SystemC data types, but they don't define a module class with a ports interface and processes. Without a minimal, self-contained, and executable example exposing your issue, you are making it difficult to others to give you good feedback. Instead of pasting all the code, you can also attach a ZIP archive and keep code snippets to the parts, which you think are relevant for your problem. I recommend you reading a good introduction book on SystemC to get familiar with it and associated modelling methodologies.

You still don't provide enough context for enabling us to give you a good response. Ideally, you should provide us with a self-contained executable example exposing your problem. It is also important to know on which platform, with which compiler and library versions you did build your application and what full error message resulted. Your code snipped seems to stem from some test program, which is part of the ac_math distribution and hosted on GitHub. So, if this gets triggered on your platform following their build instructions, I suggest to check their issue tracker and raise a new issue if needed.

No, sc_vector is part of the IEEE Std 1666-2011 (cf. to clause 8.5), which is describing SystemC including TLM-2.0 and is available for free through the IEEE Get Program. Additional information on how to use it, you may find, e.g., here, here, and here.

Be aware that SystemC itself is compiled with g++/clang++ using the following options "-Wall -Wextra -no-unused-parameter -W-no-unused-variable". Any additional warning options might trigger additional warnings inside the SystemC headers. You may therefore point g++ to the headers using "-isystem" instead of "-I".

Hello Sumit, no, gcc 9.3.0 has not yet been officially tested, as you can see from the RELEASENOTES. However, you can do so yourself by building SystemC with that compiler and running the regression test suite matching your version of the SystemC library. I am routinely using SystemC with newer compiler versions. If you should observe issues, you can report them here or even better on GitHub. Regards, Torsten

Thanks for sharing the results of debugging and fixing your issue! That's helpful for others.

You are referring to section 8.2.2.2 "Modeling noise in the time domain" in the SystemC AMS User's Guide. This document explains in section 5.3.2 "Laplace transfer functions" how to instantiate a Laplace transfer function within a TDF primitive module to filter an input signal. If you want to generate transient coloured noise, all you have to do is to specify the coefficients for that transfer function according to the characteristic of the kind of noise you want to model (see, e.g., Wikipedia as a starting point). Then, instead of feeding the input samples to the LTF functions, you would feed the samples generated by calls to function gauss_rand() to the LTF and add the return value to your signal as your coloured noise contribution. Note that std::rand() gives no guarantees on the quality of the generated random numbers. Since C++'11, there are better ways to generate pseudo-random numbers satisfying various distributions.

@coderoo: As a start, you can have a look to this blog post by Chethan. If you want to avoid having to deal with non-deterministic simulation results due to race conditions in the future, you may consider switching from Verilog to VHDL. 😉