maehne

Your question is not stupid at all, but requires knowledge of some less widely known corners of the IEEE Std 1666-2011. Typically, people constrain the word length of their data types using the template parameters, because this has the additional advantage of enforcing correct connectivity. As you noted, the port and signal types construct the value types using their default constructor. So, to configure the word lengths as required in your use case, you will have to profit from the fact that SystemC integers and vectors get their default length from the current sc_dt::sc_length_context in scope. I recommend to read up on the topic in chapter 7 of IEEE Std 1666-2011, in particular clause 7.2.3 "Base class default word length". I think this should allow you to implement all aspects of your use case.

Skimming over your code snippets, I don't see a line, which would cause the error from your thread title. Try to reduce your code to a self-contained example, which exposes the problem. As the error message states, you cannot create new modules after elaboration has finished and simulation is running.

Check IEEE Std 1666-2011 clause 7.9.8.2. sc_lv<32> has a constructor and assignment operator for uint64, so your approach should be safe. If you want to be more explicit, you can create the temporary sc_lv<32> object yourself before passing it to the write function.

As @Eyck suggested, constructor parameters should fit best your needs. You can even give them default values if it is sensible. If the number of parameters grows, grouping them in a struct may become handy. Its members can be default-initialised and you can override them with assignments before passing the whole struct to the module constructor. Personally, I like to first check for consistency and legal range for these parameters in the constructor / member function to which I pass this struct, e.g., by using assertions before actually using them for describing any behaviour/internal structure.

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".