Matt Bone

What commands did you run to do the installation? There are multiple methods for install (autoconf/configure vs. CMake) and details matter. Your message leads me to believe that you did a build and install of a Debug library. Then you tried to install a Release library, without doing a build of a Release library. Also note that it is not required to build both a Debug and Release library to run a program with SystemC. Only one variant of the library should be provided for linking into your program.

Focusing specifically on your question about synthesis, You can find a large list of high-level synthesis tools here: https://en.wikipedia.org/wiki/High-level_synthesis For synthesizing SystemC, all options are commercial ($$) tools that can target ASIC or FPGA: https://eda.sw.siemens.com/en-US/ic/catapult-high-level-synthesis/ https://www.cadence.com/en_US/home/tools/digital-design-and-signoff/synthesis/stratus-high-level-synthesis.html https://www.nec.com/en/global/prod/cwb/index.html For synthesizing C/C++ targeting FPGA, Intel/Altera and AMD/Xilinx have their own solutions: https://www.intel.com/content/www/us/en/software/programmable/quartus-prime/hls-compiler.html https://www.xilinx.com/products/design-tools/vitis/vitis-hls.html Note that Vitis deprecated support for SystemC synthesis in 2020 and is limited to C/C++ input.

The SCV Randomization guide can also be found here: https://github.com/ezchi/scv/blob/master/docs/scv/scv_random_white_paper4.pdf

There are documents included in the SCV package. This includes a Specification doc: docs/scv/scvref/vwg_1_0e.pdf However, I recommend looking through this document for answers to your questions: docs/scv/scv_random_white_paper4.pdf The white paper presents several examples that are relevant, such as constraining to a list of values, similar to "inside" in SystemVerilog. I don't think SCV has a specific "solve before" feature like SystemVerilog, but you can achieve similar with customized next() functions, or perhaps soft constraints in some cases.

The "Connections" types and macros are included in the Matchlib toolkit, found here: https://github.com/hlslibs/matchlib_toolkit These are not part of SystemC, but instead a library of components and utilities suitable for high-level synthesis of SystemC.

Ports must be bound to a signal carrying the same type as the port, so you cannot bind to the individual bits of an sc_lv and will need to create individual signals that carry sc_logic. SC_METHOD can be used to connect the sc_lv to individual sc_logic signals. The sensitivity list of a method ensures it will run when needed so you don't have to manage any sort of "forwarding" wait. You can use something like this: SC_MODULE(Add32) { sc_in<sc_lv<32>> a, b; FullAdder fa[32]; sc_out<sc_lv<32>> sums; sc_signal<sc_logic> a_sig[32], b_sig[32]; sc_signal<sc_logic> sum_sig[32]; sc_signal<sc_logic> carry_sig[32]; sc_signal<sc_logic> zero_sig; SC_HAS_PROCESS(Add32); Add32(sc_module_name nm = "Add32") { for (unsigned i=0; i < 32; i++) { fa[i].a(a_sig[i]); fa[i].b(b_sig[i]); fa[i].sum(sum_sig[i]); fa[i].carry(carry_sig[i]); if (i == 0) { fa[0].c(zero_sig); } else { fa[i].c(carry_sig[i-1]); } } // Methods to connect sc_lv <-> sc_logic SC_METHOD(connect_a); sensitive << a; SC_METHOD(connect_b); sensitive << b; SC_METHOD(connect_sums); for (unsigned i=0; i < 32; i++) { sensitive << sum_sig[i]; } SC_METHOD(tie_zero); // no sensitivity, method runs one time at startup } void connect_a() { for (unsigned i=0; i<32; i++) { a_sig[i].write(a.read()[i]); } } void connect_b() { for (unsigned i=0; i<32; i++) { b_sig[i].write(b.read()[i]); } } void connect_sums() { sc_lv<32> sumval = 0; for (unsigned i=0; i<32; i++) { sumval[i] = sum_sig[i].read(); } sums.write(sumval); } void tie_zero() { zero_sig.write(sc_logic(0)); } }; Instead of plain arrays of signals and modules, you might consider using sc_vector, which makes naming an array of sc_objects easier.

Hi @ManikantaAllam, I am not familiar with this design, but I did try the example. For me, the simulation appears successful for both SystemC and RTL (no warnings observed). The only recommendation I have is to check that your matchlib kit is up-to-date. That is, either something bundled with a toolset from 2024, or downloaded from here: https://github.com/Stuart-Swan/Matchlib-Examples-Kit-For-Accellera-Synthesis-WG

Hi Manikanta, Stuart may be out on vacation for 1-2 weeks, so I'll add some advice for today. The most common cause for simulations failing with HLS-generated RTL when the SystemC is passing, is missing resets/initiatialization of variables. In RTL waveforms, if you see X's on any RTL module outputs, this is definitely the problem. Compile with all warnings (-Wall) and optimization (-O1) for g++ to warn about uninitialized variables. For sc_module member variables, confirm that the reset section of your threads initializes all of them, including sc_signals and sc_out ports. For locally scoped variables, confirm that all native types and "not auto-initialized" types like ac_int have initial values assigned. If your system is made of multiple sc_modules communicating through channels, it is possible that the order-of-events is changed due to the latency and initiation interval of pipelined loops. A well-designed system should be agnostic to the latency changes, but complex interactions between blocks may introduce some type of ordering dependencies. Finally, HLS tools have some interesting optimizations that can potentially parallelize non-blocking channel operations that are coded in sequence in the SystemC code. This is unlikely to be the issue, but may be possible if you do a PopNB() of one channel followed by PushNB() to another channel in one of your threads. Beyond checking for these common issues, you'll need to dig into debug to understand further. The starting point for this is usually comparing waveforms between the RTL and SystemC sims. Identify the first sample in which the outputs differ, and trace back to the logic/code driving those outputs for hints on where functionality diverges.

I tried reproducing the error with the shared code and initially I could not. I see 'G x V' (8x9) ports bound correctly when compiling with g++ and my own installation of the SystemC 2.3.3 library. However, I then tried using a commercial simulator and do get the port binding error at runtime! After a trivial change to the code gave different results again, the non-deterministic behavior pointed to an uninitialized variable. The loop in your sc_main has not initialized the loop index 'g', so it is undefined whether that loop body will be entered to call init(). Compiling with clang++ -Wall will warn about this uninitialized loop index variable: experiment.cpp:131:17: warning: variable 'g' is uninitialized when used here [-Wuninitialized] for (int g; g<G; g++) { ^ experiment.cpp:131:15: note: initialize the variable 'g' to silence this warning for (int g; g<G; g++) { ^ = 0 Compiling with g++ -Wall will warn as well, but only if optimizations are enabled (-O1 or higher): experiment.cpp:131:14: warning: ‘g’ may be used uninitialized in this function [-Wmaybe-uninitialized] 131 | for (int g; g<G; g++) {

There is no connection between the sc_clock "generator" declared in sc_main and the sc_signal 'clk' in TopLevelModule. This means the 'clk' signal connected to your decode instance is not toggling. You have two options: Move the sc_clock generator inside the TopLevelModule, to replace the floating sc_signal. Change the TopLevelModule to take the clock as an input (sc_in_clk clk), and in sc_main connect the sc_clock generator 'clk' to the input port: TOPMODULE.clk(clk)