intel / systemc-compiler Goto Github PK

This tool translates synthesizable SystemC code to synthesizable SystemVerilog.

License: Other

C++ 67.89% CMake 2.13% Shell 0.22% C 2.24% Makefile 0.37% M4 0.26% Batchfile 0.04% Roff 0.01% Assembly 0.84% Perl 0.05% Awk 0.02% SystemVerilog 25.78% Python 0.14%

systemc hls hardware-designs llvm clang

systemc-compiler's Introduction

Intel® Compiler for SystemC*

*Other names and brands may be claimed as the property of others.

Introduction

Intel® Compiler for SystemC* (ICSC) translates synthesizable SystemC design into equvivalent SystemVerilog code.

ICSC checks a SystemC design for common coding mistakes and generates human-readable SystemVerilog code. The tool supports SystemC synthesizable subset in method and thread processes, and arbitrary C++ code in module constructors. ICSC is based on Clang/LLVM 15.0.7 and includes SystemC 3.0.0 RC.

See more information at Intel Compiler for SystemC wiki.

Common SystemC Library

Common SystemC Library consists of types, modules and functions which could be used in SystemC designs and testbench code. The main part of the library are communication channels including Target/Initiator, FIFO, Register and others. The channels have functional interfaces similar to TLM 1.0.

There are Communication channels training slides.

See more information at Common SystemC Library .

License

ICSC is distributed under the Apache License v2.0 with LLVM Exceptions.

Getting started

ICSC is based on Clang/LLVM frontend and can be installed at most Linux OS. There is install.sh script that downloads and builds ICSC and the required dependencies at SLES12, Ubuntu 22.04, and Ubuntu 20.04.

An instruction how to install and run ISCS is given at Getting started.

Documentation

User guide document describes installation procedure, run tool options, preparation of SystemC design for synthesis, tool extensions and advanced verification features.

ICSC supports SystemC Synthesizable Subset. Details of SystemC/C++ subset supported are described at SystemC/C++ supported.

Publications

SystemC-to-Verilog Compiler: a productivity-focused tool for hardware design in cycle-accurate SystemC at DvCon'2019
Temporal assertions in SystemC at DvCon'2020 and SystemC evolution day'2020
Intel Compiler for SystemC and SystemC common library at CHIPS tech summit 2022

Help

To get help please submit your question or issue

systemc-compiler's People

Contributors

Stargazers

Watchers

systemc-compiler's Issues

Please avoid nonblocking assignments in always_comb blocks

With reference to the SystemC Fika 2021, I noticed that there were some nonblocking assignments found in generated always_comb blocks. While this may not cause a problem for synthesis, it will definitely create problems in simulation.

Building and installing ICSC errors

Hi,

I'm running a manual installation for ICSC and could build and install Protobuf and LLVM/Clang successfully.
But when building ICSC i got the following errors:

[ 72%] Building CXX object sc_tool/CMakeFiles/SCTool.dir/lib/sc_tool/expr/ScParseExpr.cpp.o
In file included from /s/mimagdy/test/icsc/sc_tool/lib/sc_tool/cfg/SValue.h:15:0,
from /s/mimagdy/test/icsc/sc_tool/lib/sc_tool/cfg/SValue.cpp:12:
/s/mimagdy/test/icsc/sc_tool/lib/sc_tool/diag/ScToolDiagnostic.h:47:24: error: expected ‘;’ at end of member declaration
const char* what() const
^
/s/mimagdy/test/icsc/sc_tool/lib/sc_tool/diag/ScToolDiagnostic.h:48:5: error: ‘_GLIBCXX_TXN_SAFE_DYN’ does not name a type
_GLIBCXX_TXN_SAFE_DYN _GLIBCXX_USE_NOEXCEPT override {
^
/s/mimagdy/test/icsc/sc_tool/lib/sc_tool/diag/ScToolDiagnostic.h:47:17: error: looser throw specifier for ‘virtual const char* sc::InternalErrorException::what() const’

I got to know that it may be a c compiler issue but i'm using the recommended versions:
-- The C compiler identification is GNU 4.8.5
-- The CXX compiler identification is GNU 4.8.5
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found LLVM 7.0.0

-- CMAKE_CXX_STANDARD = 17
-- CMAKE_CXX_STANDARD_REQUIRED =
-- CMAKE_SYSTEM = Linux-3.10.0-693.21.1.el7.x86_64
-- CMAKE_SYSTEM_PROCESSOR = x86_64
-- QT_ARCH = x86_64
-- Threads_FOUND = TRUE
-- CMAKE_USE_PTHREADS_INIT = 1
-- CMAKE_THREAD_LIBS_INIT = -pthread

‘llvm::isa_and_nonnull’ has not been declared - errors building icsc 'SValue.cpp'

in the demand of an open source systemc to verilog translator I tryed building icsc. The build is proceeding up to:

...
[ 63%] Built target systemc
[ 65%] Built target sc_elab_proto
[ 66%] Built target SysCRTTI
[ 67%] Built target systemcPCH
[ 67%] Building CXX object sc_tool/CMakeFiles/SCTool.dir/lib/sc_tool/cfg/SValue.cpp.o

than the compiler emits errors (beginning)

In file included from /home/mz/github.com/icsc/include/clang/Basic/DiagnosticIDs.h:17,
                 from /home/mz/github.com/icsc/include/clang/Basic/Diagnostic.h:17,
                 from /home/mz/github.com/icsc/icsc/sc_tool/lib/sc_tool/diag/ScToolDiagnostic.h:16,
                 from /home/mz/github.com/icsc/icsc/sc_tool/lib/sc_tool/cfg/SValue.h:15,
                 from /home/mz/github.com/icsc/icsc/sc_tool/lib/sc_tool/cfg/SValue.cpp:12:
/home/mz/github.com/icsc/include/clang/Basic/LLVM.h:57:15: error: ‘llvm::isa_and_nonnull’ has not been declared
   57 |   using llvm::isa_and_nonnull;
      |               ^~~~~~~~~~~~~~~
In file included from /home/mz/github.com/icsc/include/clang/AST/Type.h:22,
                 from /home/mz/github.com/icsc/icsc/sc_tool/lib/sc_tool/systemc/ScChannel.h:19,
                 from /home/mz/github.com/icsc/icsc/sc_tool/lib/sc_tool/cfg/SValue.h:16,
                 from /home/mz/github.com/icsc/icsc/sc_tool/lib/sc_tool/cfg/SValue.cpp:12:
/home/mz/github.com/icsc/include/clang/AST/TemplateName.h:195:74: error: wrong number of template arguments (4, shou
ld be 2)
...

The build and installation of protobuf and llvm+clang on an actual Ubunutu 20.04 was done as described and without errors.

Any glue what's going on?
Is the actual systemc-compiler build actually working?

Is there any intermediate code similar to AST generation during conversion to SystemVerilog

The ICSC User Guide says “SystemVerilog code generation is done with svc_target function.” I want to know how the transformation is realized and whether there is an intermediate part between the two language.

support for fixed point datatypes sc_fixed sc_ufixed

Can you outline what would be needed to add support for sc_fixed and sc_ufixed data types?

I'd be happy to attempt to contribute, but I must admit I am not that familiar with llvm..

Provide unique name for comb variable assigned in CTHREAD reset

Support sc_bv type

multiple level mif array cause error

I design 3 modules: TestA, TestB, and TestC.
Test B and TestC are mif.

3 level hierarchy architecture: TestA is the top module, TestB is TestA’s child module, TestC is TestB’s child module.
TestB is instantiated as a mif array in TestA, TestC is instantiated as a mif array in TestB.

It will cause ICSC tool error: ScTool internal fatal error : No record in getBaseClass()

But when not instantiate TestC (or TestC is not a mif array), it means not have multiple level mif array, it will be correct.

Is it a bug of ICSC tool? How can I avoid it? Thanks very much.

Equivalence Checking - SystemC vs. Generated SystemVerilog

Greetings,

This is a feature request for equivalence checking of the synthesized SystemVerilog code vs the SystemC design. Is such an enhancement planned?

Regards,
Shashank V M

Documentation detailing thread generation process

To help me understand how my threaded design runs through the compiler, I wanted to understand your approach to generating the state machine from threads with waits. I've read your documentation, and looked at your DVCON presentations. I was hoping for more details and started looking at ScTraverseProc.cpp, run(). I was wondering if there are additional insights on how the generation is done to help better understand the approach taken in ScTraverseProc.cpp?

Incorrect record assignment for record reference

The use of new operators

Some of the tests seem to use new, sc_new<>, sc_new_array<>. It seems that the synthesizable reference suggests that new can be used only for SC_MODULE types and arrays. However, some tests show it being used for dynamically allocating ports (new sc_out<bool>("p")). Does systemc-compiler go beyond what is required by the reference?

What is the purpose of sc_new and sc_new_array?

Can tlm interfaces be used?

Hierarchy:

TOP
--> TB
--> DUT

DUT module:

sc_port< tlm_nonblocking_get_peek_if< bool > > status;
...
if (status->nb_can_get())
{
bool status_in;
status->nb_get(status_in);
}

TB module:

sc_port< tlm_nonblocking_put_if< bool > > status;
...
if (status->nb_can_put())
{
bool status_out = true;
status->nb_put(status_out);
}

TOP module:

DUT dut;
TB tb;
tlm_fifo chan_status;
...
tb.bind(chan_status);
dut.bind(chan_status);

Errors:

The above code will end up with errors:

Intel Compiler for SystemC (ICSC) version 1.4.31, Jun 17,2022

Top-level module is Control
error: Port bound to incorrect signal: TOP.dut.status
fatal error: ScTool internal fatal error : No global static constant integer result

SystemC-to-Verilog translation, ERROR

2 errors generated.

const parameter can not support sc_biguint

When I use sc_biguint as type of one const member parameter, which data bits more than 64, will cause error.

One example, const sc_biguint<65> data;
error: Unsupported type: 'const sc_dt::sc_biguint<65>'

Is this a limitation of this tool?
Thanks very much.

const member parameter error

i define one const member parameter (const unsigned int tRCD; ) in class Test (example), class Test is a modular interface. Then use class Test as: Test t_test[10].
After SCT operation, i see the sv_out/.sv file, the code as:
localparam logic [31] tRCD = `d22; //on the top module, because Test is the modular interface

In each t_test[i]，I think it should use tRCD the whole 32bit value. But it use as:
//example
t_wait_time = tRCD[i];// i think it shoud be t_wait_time = tRCD here.

Please help me check whether it is a limitation for ScTool? Thanks very much.

Enable unused variable/constant and statements removing

Report error for side-effect in assertions, cout and other service functions

assert(data = j++);

Support function call in SCT_ASSERT

CMake Error at CMakeLists.txt:28 (svc_target): Unknown CMake command "svc_target".

Hello，

I have installed icsc, but failed to test the example "counter" with the error below:

CMake Error at CMakeLists.txt:28 (svc_target):
Unknown CMake command "svc_target".

Does anyone have some suggestions? Thanks.

Check multiple SV modules created for the same SC module

For a module which pins connected to array elements.

subtraction and left side assignment

having SystemC code

sc_in<uint16_t> a;
sc_in<uint16_t> b;
uint16_t result;
...
result = a.read() - b.read();

resulting in SystemVerilog code

logic [15:0] a;
logic [15:0] b;
logic [15:0] result;
...
result =  signed'({1'b0, a}) - signed'({1'b0, b})

Given (in my application) that b is always smaller than just a

result = a - b;

should work.
My issue is, that checking the code with verilator it will result in a warning

%Warning-WIDTH: Operator ASSIGN expects 16 bits on the Assign RHS, but Assign RHS's SUB generates 17 bits.

So my question is: Is the extension to 17 bit correct and required (in terms of the SV standards) ?

Connecting SystemC compiler to open source ASIC/FPGA tooling and demo with Google's Skywater PDK?

Thanks to the funded provided by DARPA there is an increasingly capable, fully automated, RTL to GDS toolchain for creation ASICs called OpenROAD (https://theopenroadproject.org/). To help support the project, Google has partnered with SkyWater to release a fully open source, manufacturable 130nm PDK (https://github.com/google/skywater-pdk) and with efabless a run a regular no-cost MPW program for open source designs.

Google has also been actively working with Antmicro on improve the state of SystemVerilog tooling in the open source tooling with projects now being hosted by CHIPS Alliance like;

https://opensource.googleblog.com/2021/09/open-source-systemverilog-tools-in-asic-design.html
https://github.com/chipsalliance/sv-tests
https://github.com/chipsalliance/Surelog
https://github.com/chipsalliance/UHDM -- Library and connection to tools like Yosys and Verilator
https://github.com/chipsalliance/verible -- Developer tooling for SystemVerilog like an auto-formatter, linter and library to create more!
- https://antmicro.com/blog/2021/08/verible-integration-with-github-actions/

There is also a bunch of work around fully open source RTL to Bitstream flows here too -- see https://chipsalliance.org/announcement/2022/02/18/chips-alliance-forms-f4pga-workgroup-to-accelerate-adoption-of-open-source-fpga-tooling/

It would be awesome to have your SystemC compiler as a frontend for these tools so that you could have a complete open source SystemC to GDS or SystemC to bitstream flows. It would be even more awesome if someone used that to then tape out a real ASIC on the no-cost MPW program.

Due to everything here being open source you could even have an end-to-end demo for SystemC to GDS which results in an actually manufacturable IC without need any set up!

Record Type Object errors

I have problems with a Struct i use for data storage.

struct SWbufEntry{
    sc_uint<30> adr;       
    sc_uint<32> data;
    sc_uint<4> valid;      
    sc_uint<3> special;    
    
    // Necessary operators for using this structure as signals...
    bool operator== (const SWbufEntry &t) const {
        return (adr == t.adr) && (valid == t.valid) && (special == t.special)  && (data == t.data);
    }

    // Displaying
    friend ostream& operator << ( ostream& os, const SWbufEntry &t ) {
        os << "adr:" << t.adr << " data:" << t.data << " valid:" << t.valid;
        return os;
    }
    //Overload function
    friend void sc_trace( sc_trace_file* f, const SWbufEntry& t, const std::string& _s ) {
       sc_trace( f, t.adr, _s + ".adr" );
       sc_trace( f, t.data, _s + ".data" );
       sc_trace( f, t.valid, _s + ".valid" );
       sc_trace( f, t.special, _s + ".special" );
    }
};

Whenever I try to access the member variables I get following errors:

Top-level module is MLsu
In file included from /home/marco/Workspace/intel_compiler/icsc/designs/lsu_test/build/LsuModule.sctool.cpp:6:
/home/marco/Workspace/intel_compiler/icsc/designs/lsu_test/lsu.cpp:449:28: error: No record object found for member call : ARR_16[1](4) Unknown
            wbuf_dirty0 = (wbuf_var[1].valid != 0) || (wbuf_var[1].special != 0);
                           ^
/home/marco/Workspace/intel_compiler/icsc/designs/lsu_test/lsu.cpp:449:56: error: No record object found for member call : ARR_16[1](4) Unknown
            wbuf_dirty0 = (wbuf_var[1].valid != 0) || (wbuf_var[1].special != 0);
                                                       ^
/home/marco/Workspace/intel_compiler/icsc/designs/lsu_test/lsu.cpp:463:28: error: No record object found for member call : ARR_16[1](4) Unknown
            wbuf_dirty0 = (wbuf_var[1].valid != 0) || (wbuf_var[1].special != 0);
                           ^
/home/marco/Workspace/intel_compiler/icsc/designs/lsu_test/lsu.cpp:463:56: error: No record object found for member call : ARR_16[1](4) Unknown
            wbuf_dirty0 = (wbuf_var[1].valid != 0) || (wbuf_var[1].special != 0);
                                                       ^
/home/marco/Workspace/intel_compiler/icsc/designs/lsu_test/lsu.cpp:467:17: error: No record object found for member call : ARR_16[0](4) Unknown
                wbuf_var[n].adr = wbuf_var[n + 1].adr;
                ^
/home/marco/Workspace/intel_compiler/icsc/designs/lsu_test/lsu.cpp:467:35: error: No record object found for member call : ARR_16[1](4) Unknown
                wbuf_var[n].adr = wbuf_var[n + 1].adr;
                                  ^
/home/marco/Workspace/intel_compiler/icsc/designs/lsu_test/lsu.cpp:468:17: error: No record object found for member call : ARR_16[0](4) Unknown
                wbuf_var[n].data = wbuf_var[n + 1].data;
                ^
/home/marco/Workspace/intel_compiler/icsc/designs/lsu_test/lsu.cpp:468:36: error: No record object found for member call : ARR_16[1](4) Unknown
                wbuf_var[n].data = wbuf_var[n + 1].data;
                                   ^
/home/marco/Workspace/intel_compiler/icsc/designs/lsu_test/lsu.cpp:469:17: error: No record object found for member call : ARR_16[0](4) Unknown
                wbuf_var[n].valid = wbuf_var[n + 1].valid;
                ^
/home/marco/Workspace/intel_compiler/icsc/designs/lsu_test/lsu.cpp:469:37: error: No record object found for member call : ARR_16[1](4) Unknown
                wbuf_var[n].valid = wbuf_var[n + 1].valid;
                                    ^
/home/marco/Workspace/intel_compiler/icsc/designs/lsu_test/lsu.cpp:470:17: error: No record object found for member call : ARR_16[0](4) Unknown
                wbuf_var[n].special = wbuf_var[n + 1].special;
                ^
/home/marco/Workspace/intel_compiler/icsc/designs/lsu_test/lsu.cpp:470:39: error: No record object found for member call : ARR_16[1](4) Unknown
                wbuf_var[n].special = wbuf_var[n + 1].special;
                                      ^
/home/marco/Workspace/intel_compiler/icsc/designs/lsu_test/lsu.cpp:474:13: error: No record object found for member call : ARR_16[3](4) Unknown
            wbuf_var[CFG_LSU_WBUF_SIZE - 1].adr = 0;
            ^
/home/marco/Workspace/intel_compiler/icsc/designs/lsu_test/lsu.cpp:475:13: error: No record object found for member call : ARR_16[3](4) Unknown
            wbuf_var[CFG_LSU_WBUF_SIZE - 1].data = 0;
            ^
/home/marco/Workspace/intel_compiler/icsc/designs/lsu_test/lsu.cpp:476:13: error: No record object found for member call : ARR_16[3](4) Unknown
            wbuf_var[CFG_LSU_WBUF_SIZE - 1].valid = 0;
            ^
/home/marco/Workspace/intel_compiler/icsc/designs/lsu_test/lsu.cpp:477:13: error: No record object found for member call : ARR_16[3](4) Unknown
            wbuf_var[CFG_LSU_WBUF_SIZE - 1].special = 0;
            ^
In file included from /home/marco/Workspace/intel_compiler/icsc/designs/lsu_test/build/LsuModule.sctool.cpp:6:
/home/marco/Workspace/intel_compiler/icsc/designs/lsu_test/lsu.cpp:131:9: fatal error: Code after function return is prohibited
        return 0;
        ^
------------------------------------------------
  Module number       1
  Process number      2
------------------------------------------------
  General statements  161
  Control statements  53
  Assertions          0
  Wait statements     2
------------------------------------------------
----------------------------------------------------------------
 SystemC-to-Verilog translation, OK 
----------------------------------------------------------------
13 warnings and 17 errors generated.

I dont know how i can fix this error type. Do you have any advice?

~ Marco

sys::CleanupOnSignal error

OpenSuSe Tumbleweed linux x5 6.4.6-1-default
Fresh clone
./install.sh

Getting this error:

[  3%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/Signals.cpp.o
In file included from /home/drom/work/github/intel/systemc-compiler/build_deps/llvm-12.0.1.src/lib/Support/Signals.cpp:14:
/home/drom/work/github/intel/systemc-compiler/build_deps/llvm-12.0.1.src/include/llvm/Support/Signals.h:119:8: error: variable or field ‘CleanupOnSignal’ declared void
  119 |   void CleanupOnSignal(uintptr_t Context);
      |        ^~~~~~~~~~~~~~~
/home/drom/work/github/intel/systemc-compiler/build_deps/llvm-12.0.1.src/include/llvm/Support/Signals.h:119:24: error: ‘uintptr_t’ was not declared in this scope
  119 |   void CleanupOnSignal(uintptr_t Context);
      |                        ^~~~~~~~~

In file included from /home/drom/work/github/intel/systemc-compiler/build_deps/llvm-12.0.1.src/lib/Support/Signals.cpp:225:
/home/drom/work/github/intel/systemc-compiler/build_deps/llvm-12.0.1.src/lib/Support/Unix/Signals.inc:348:44: error: ‘void llvm::sys::CleanupOnSignal(uintptr_t)’ should have been declared inside ‘llvm::sys’
  348 | void sys::CleanupOnSignal(uintptr_t Context) {
      |                                            ^
make[2]: *** [lib/Support/CMakeFiles/LLVMSupport.dir/build.make:1882: lib/Support/CMakeFiles/LLVMSupport.dir/Signals.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/Makefile2:9937: lib/Support/CMakeFiles/LLVMSupport.dir/all] Error 2
make: *** [Makefile:156: all] Error 2

CMake Error at CMakeLists.txt:107 (install): install FILES given no DESTINATION!

Hello，

I am intalling ICSC manually. I have already install the dependencies : Protobuf, Clang and LLVM. When i installed icsc by running :
cmake ../ -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=$ICSC_HOME

I got the errors:
CMake Error at CMakeLists.txt:107 (install):
install FILES given no DESTINATION!

CMake Error at CMakeLists.txt:116 (install):
install DIRECTORY given no DESTINATION!

Hope that you have some suggestions to solve the problem.

Using nested Record leads to ambigious error

Hi,

I was very happy to see you implemented the capability to use structs in channels. I was experimenting with this feature and found, that nesting structs is not fully supported yet.

Seemingly nesting a struct with a single member is supported, adding a second member variable leads to the following error in
the synthesis step (when calling the _sctool binary). In simulation, nested structs are supported and traced correctly.

--------------------------------------------------------------
 Intel Compiler for SystemC (ICSC) version 1.5.5, Jan 27,2023
--------------------------------------------------------------
Top-level module is MMemu
Memu_sctool: /data/icsc_1.5.5/include/llvm/ADT/SmallVector.h:277: T& llvm::SmallVectorTemplateCommon<T, <template-parameter-1-2> >::operator[](llvm::SmallVectorTemplateCommon<T, <template-parameter-1-2> >::size_type) [with T = sc_elab::ObjectView; <template-parameter-1-2> = void; llvm::SmallVectorTemplateCommon<T, <template-parameter-1-2> >::reference = sc_elab::ObjectView&; llvm::SmallVectorTemplateCommon<T, <template-parameter-1-2> >::size_type = long unsigned int]: Assertion `idx < size()' failed.
Abgebrochen

Here the code for the structs i wanted to use:

struct Srecrec {
    sc_uint<34> z;
    // sc_uint<23> k; //error when uncommented

    bool operator== (const Srecrec& other) {
        return (z == other.z);
        // return (z == other.z, k == other.k);
    }

    friend void sc_trace( sc_trace_file *tf, const Srecrec &t, const std::string &name ) {
        PN_TRACE_R(tf, t, z, name);
        // PN_TRACE_R(tf, t, k, name);
    }

    friend ::std::ostream& operator<< (::std::ostream& os, const Srecrec& s) {
        os << "{" << s.z << "}";
        return os;
    }
};
struct SRec {
    
    int x;
    sc_uint<2> y;
    Srecrec z;

    bool operator== (const SRec& other) {
        return (x == other.x && y == other.y && z == other.z);
    }

    friend void sc_trace( sc_trace_file *tf, const SRec &t, const std::string &name ) {
        PN_TRACE_R(tf, t, y, name);
        PN_TRACE_R(tf, t, x, name);
        PN_TRACE_R(tf, t, z, name);
    }

    friend ::std::ostream& operator<< (::std::ostream& os, const SRec& s) {
        os << "{" << s.x << s.y << "}";
        return os;
    }

};

// PN TRACE MACRO FOR REFERENCE
    #define PN_TRACE_R(TF, OBJ, MEMBER, STR)                        \
        {                                                           \
            if (TF) sc_trace (TF, (OBJ).MEMBER, STR + "."#MEMBER);  \
        }

You may recognize the "PN_TRACE_R" from Milemarco and the ParaNut, I too am working on that project.

Greetings

Instructions for SystemC simulation and viewing SV file does not work.

Greetings,

There is a minor error in the Linux commands for SystemC simulation. I have made a pull-request to fix that.
The SystemC simulation of counter does not stop because there is no time limit. I have fixed that and enhanced the testbench so that the user can get feedback on the example simulation. This is included in my pull-request.

Clang/LLVM 14 support

Error with ibm128 type -- needs to debug it

Header cassert not found

Steps to reproduce:

export $ICSC_HOME=/tmp/icsc
git clone https://github.com/intel/systemc-compiler $ICSC_HOME
cd $ICSC_HOME
git checkout 59d79d7
./install.sh

The compilation will run until "Generating SystemC precompiled header...." is output.
It then terminates by "fatal error: 'cassert' file not found".

Running make VERBOSE=1from $ICSC_HOME/build_icsc_rel`, it reveals the compilation command to be:

../bin/clang++ -Xclang -emit-pch -x c++-header /mnt/data/projects/intel-systemc/icsc/systemc/src/systemc.h -o /mnt/data projects/intel-systemc/icsc/build_icsc_rel/systemc/systemc.h.pch -D__SC_TOOL__ -D__SC_TOOL_ANALYZE__ -DNDEBUG -std=c++17 -I/mnt/data/projects/intel-systemc/icsc/systemc/src

Adding -v to this compile command:

clang version 12.0.1 (https://github.com/intel/systemc-compiler 59d79d73890d321aec6c9b25cf9c0e0e2039c70c)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /mnt/data/projects/intel-systemc/icsc/build_icsc_rel/../bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/11
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/12
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/12
Candidate multilib: .;@m64
Selected multilib: .;@m64
 (in-process)
 "/mnt/data/projects/intel-systemc/icsc/bin/clang-12" -cc1 -triple x86_64-unknown-linux-gnu -emit-pch -disable-free -main-file-name systemc.h -mrelocation-model static -mframe-pointer=all -fmath-errno -fno-rounding-math -mconstructor-aliases -munwind-tables -target-cpu x86-64 -tune-cpu generic -fno-split-dwarf-inlining -debugger-tuning=gdb -v -resource-dir /mnt/data/projects/intel-systemc/icsc/lib/clang/12.0.1 -D __SC_TOOL__ -D __SC_TOOL_ANALYZE__ -D NDEBUG -I /mnt/data/projects/intel-systemc/icsc/systemc/src -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++ -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/x86_64-linux-gnu -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/backward -internal-isystem /usr/local/include -internal-isystem /mnt/data/projects/intel-systemc/icsc/lib/clang/12.0.1/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++17 -fdeprecated-macro -fdebug-compilation-dir /mnt/data/projects/intel-systemc/icsc/build_icsc_rel -ferror-limit 19 -fgnuc-version=4.2.1 -fcxx-exceptions -fexceptions -fcolor-diagnostics -emit-pch -faddrsig -o /mnt/data/projects/intel-systemc/icsc/build_icsc_rel/systemc/systemc.h.pch -x c++-header /mnt/data/projects/intel-systemc/icsc/systemc/src/systemc.h
clang -cc1 version 12.0.1 based upon LLVM 12.0.1 default target x86_64-unknown-linux-gnu
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/backward"
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
 /mnt/data/projects/intel-systemc/icsc/systemc/src
 /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++
 /usr/local/include
 /mnt/data/projects/intel-systemc/icsc/lib/clang/12.0.1/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.

Move in-reset assertions into IF branch

Question regarding missing SystemC features

Hi,

First of all, thanks for starting this great project I think this is really useful.

I just really have questions regarding missing features, or rather perhaps the ones I mostly care about and what the plans are for those. These are:

Sequential Methods support
Reading outputs within a sequential process
Records:
a. Support for base class
b. Support for record in record
c. Support for record as signal/port template argument
Support for ac_int. These types have many advantages over sc_dt ones and seem to be reasonably popular in HLS scope

I'm not sure 2 above is illegal, I think it might actually be ok but then maybe not deemed a good practice. If one would like to address that, for every module output one could instantiate a module-local logical, assign the output to this local logical (with an assign statement) and then use the latter inside processes to read/write freely instead of the output.

Anyway, my question is whether there's some kind of roadmap lined up for this project that may address some of these? Would you accept contributions regarding any of these, and what would be the best way to proceed.

Many thanks!

CMakeLists.txt overwritten

I find it very poor practice to overwrite the top-level CMakeLists.txt in the repository.
It means that you cannot run install_icsc.sh twice without restoring the repository.

Please, if you need another CMakeLists.txt for the install root, make the installation to a folder outside the repository.
That way, you may also install and delete the sources if they are not required.

Running CI

Would you be interested in using Github Actions to run CI on the compilation and tests?

Remove unused register declaration and initialization in always_ff reset section

Required for some projects

Examples dvcon20 fifo not working as expected

Hi there,
I looked into the dvcon20 fifo example. Seems like there is an issue with the valid and/or ready signals of the fifo(s) within AdvFifo.h. When modifying the test_fifo.cpp by intruducing additional wait cycles into either the reqProc() or respProc() of the Dut, the expected behaviour is waiting of the other process. Both SC_CTHREADS check the fifo for valid/ready before they read/write data from/to it.

  void reqProc() {
      wait();
      
      while(true) {
          if (fifo.ready()) {
              fifo.push(in.read());
          }
          wait();
      }
  }
  
  void respProc() {
      wait();
      
      while(true) {
          if (fifo.valid()) {
              out = fifo.pop();
          }
          wait();
      }
  }

What actually happens is multiple readouts of the same value or missing values respectively. The test within the testbench is also not sufficient to ensure the functionality of the fifo. A counter is used as an input and it is only checked if the output of the fifo is not larger than its input.

  for (int i = 0; i < N; i++) {
      in = i;
      wait();
      
      if (out.read() > in.read()) {
          cout << "in " << in.read() << " out " << out.read() << endl;
          assert (false && "error");
      }
  }

A fifo should output the exact same values as it received before. The testbench should be adapted to ensure this behaviour and detect multiple readouts of the same value or missing values.

Error when building ICSC in Debug mode

I tried to build the ICSC in Debug mode.

I build the protobuf, llvm and clang all in debug mode.
When building ICSC in debug mode i encountered some problems.
I figured out that
cmake ../ -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=$ICSC_HOME
doesn't copy the sctcommon directory into the include directory.
This is sovable by copying the directory directly there.
But then when running make -j8 VERBOSE=1 i get an error around 61% in the sct_property.h

see here:

In file included from /data/ICSC_debug/icsc/examples/dvcon20/test_simple.cpp:2:
/data/ICSC_debug/icsc/examples/dvcon20/test_simple.cpp: In member function ‘void Dut<M>::thread_proc()’:
/data/ICSC_debug/include/sctcommon/sct_assert.h:227:50: error: expected identifier before ‘]’ token
  227 |                     [&, SCT_ITER_STR(__VA_ARGS__)]()->bool{return ( LE );},\
      |                                                  ^
/data/ICSC_debug/include/sctcommon/sct_assert.h:266:30: note: in expansion of macro ‘SCT_ASSERT_LOOPN’
  266 | #define SCT_ASSERT_LOOP(...) SCT_ASSERT_LOOPN(__VA_ARGS__)
      |                              ^~~~~~~~~~~~~~~~
/data/ICSC_debug/icsc/examples/dvcon20/test_simple.cpp:70:7: note: in expansion of macro ‘SCT_ASSERT_LOOP’
   70 |       SCT_ASSERT_LOOP(enbl[i], SCT_TIME(1), !enbl[i], i);
      |       ^~~~~~~~~~~~~~~
/data/ICSC_debug/include/sctcommon/sct_assert.h:228:50: error: expected identifier before ‘]’ token
  228 |                     [&, SCT_ITER_STR(__VA_ARGS__)]()->bool{return ( RE );},\
      |                                                  ^
/data/ICSC_debug/include/sctcommon/sct_assert.h:266:30: note: in expansion of macro ‘SCT_ASSERT_LOOPN’
  266 | #define SCT_ASSERT_LOOP(...) SCT_ASSERT_LOOPN(__VA_ARGS__)
      |                              ^~~~~~~~~~~~~~~~
/data/ICSC_debug/icsc/examples/dvcon20/test_simple.cpp:70:7: note: in expansion of macro ‘SCT_ASSERT_LOOP’
   70 |       SCT_ASSERT_LOOP(enbl[i], SCT_TIME(1), !enbl[i], i);
      |       ^~~~~~~~~~~~~~~
/data/ICSC_debug/include/sctcommon/sct_assert.h:233:17: error: expected primary-expression before ‘)’ token
  233 |                 );}
      |                 ^
/data/ICSC_debug/include/sctcommon/sct_assert.h:266:30: note: in expansion of macro ‘SCT_ASSERT_LOOPN’
  266 | #define SCT_ASSERT_LOOP(...) SCT_ASSERT_LOOPN(__VA_ARGS__)
      |                              ^~~~~~~~~~~~~~~~
/data/ICSC_debug/icsc/examples/dvcon20/test_simple.cpp:70:7: note: in expansion of macro ‘SCT_ASSERT_LOOP’
   70 |       SCT_ASSERT_LOOP(enbl[i], SCT_TIME(1), !enbl[i], i);
      |       ^~~~~~~~~~~~~~~

and a few lines later

/data/ICSC_debug/icsc/examples/dvcon20/test_simple.cpp:72:10:   required from ‘void Dut<M>::thread_proc() [with unsigned int M = 32]’
/data/ICSC_debug/icsc/examples/dvcon20/test_simple.cpp:25:9:   required from ‘Dut<M>::Dut(sc_core::sc_module_name) [with unsigned int M = 32]’
/data/ICSC_debug/icsc/examples/dvcon20/test_simple.cpp:92:23:   required from here
/data/ICSC_debug/include/sctcommon/sct_property.h:368:32: error: no matching function for call to ‘sc_core::sc_spawn_options::set_sensitivity(int*&)’
  368 |             opt.set_sensitivity(event);
      |             ~~~~~~~~~~~~~~~~~~~^~~~~~~
In file included from /data/ICSC_debug/icsc/systemc/src/sysc/kernel/sc_method_process.h:46,
                 from /data/ICSC_debug/icsc/systemc/src/systemc:77,
                 from /data/ICSC_debug/icsc/systemc/src/systemc.h:219,
                 from /data/ICSC_debug/icsc/examples/dvcon20/test_simple.cpp:1:
/data/ICSC_debug/icsc/systemc/src/sysc/kernel/sc_spawn_options.h:88:10: note: candidate: ‘void sc_core::sc_spawn_options::set_sensitivity(const sc_core::sc_event*)’
   88 |     void set_sensitivity(const sc_event* event)
      |          ^~~~~~~~~~~~~~~
/data/ICSC_debug/icsc/systemc/src/sysc/kernel/sc_spawn_options.h:88:42: note:   no known conversion for argument 1 from ‘int*’ to ‘const sc_core::sc_event*’
   88 |     void set_sensitivity(const sc_event* event)
      |                          ~~~~~~~~~~~~~~~~^~~~~
/data/ICSC_debug/icsc/systemc/src/sysc/kernel/sc_spawn_options.h:91:10: note: candidate: ‘void sc_core::sc_spawn_options::set_sensitivity(sc_core::sc_port_base*)’
   91 |     void set_sensitivity(sc_port_base* port_base)
      |          ^~~~~~~~~~~~~~~
/data/ICSC_debug/icsc/systemc/src/sysc/kernel/sc_spawn_options.h:91:40: note:   no known conversion for argument 1 from ‘int*’ to ‘sc_core::sc_port_base*’
   91 |     void set_sensitivity(sc_port_base* port_base)
      |                          ~~~~~~~~~~~~~~^~~~~~~~~
/data/ICSC_debug/icsc/systemc/src/sysc/kernel/sc_spawn_options.h:94:10: note: candidate: ‘void sc_core::sc_spawn_options::set_sensitivity(sc_core::sc_interface*)’
   94 |     void set_sensitivity(sc_interface* interface_p)
      |          ^~~~~~~~~~~~~~~
/data/ICSC_debug/icsc/systemc/src/sysc/kernel/sc_spawn_options.h:94:40: note:   no known conversion for argument 1 from ‘int*’ to ‘sc_core::sc_interface*’
   94 |     void set_sensitivity(sc_interface* interface_p)
      |                          ~~~~~~~~~~~~~~^~~~~~~~~~~
/data/ICSC_debug/icsc/systemc/src/sysc/kernel/sc_spawn_options.h:97:10: note: candidate: ‘void sc_core::sc_spawn_options::set_sensitivity(sc_core::sc_export_base*)’
   97 |     void set_sensitivity(sc_export_base* export_base)
      |          ^~~~~~~~~~~~~~~
/data/ICSC_debug/icsc/systemc/src/sysc/kernel/sc_spawn_options.h:97:42: note:   no known conversion for argument 1 from ‘int*’ to ‘sc_core::sc_export_base*’
   97 |     void set_sensitivity(sc_export_base* export_base)
      |                          ~~~~~~~~~~~~~~~~^~~~~~~~~~~
/data/ICSC_debug/icsc/systemc/src/sysc/kernel/sc_spawn_options.h:100:10: note: candidate: ‘void sc_core::sc_spawn_options::set_sensitivity(sc_core::sc_event_finder*)’
  100 |     void set_sensitivity(sc_event_finder* event_finder)
      |          ^~~~~~~~~~~~~~~
/data/ICSC_debug/icsc/systemc/src/sysc/kernel/sc_spawn_options.h:100:43: note:   no known conversion for argument 1 from ‘int*’ to ‘sc_core::sc_event_finder*’
  100 |     void set_sensitivity(sc_event_finder* event_finder)
      |                          ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~

I set the -g flag inside the CmakeLists.txt in the sctool directory, that solved the problem for me.

Primitive channel

I tried to synthesize a module that has a primitive channel. I used an example simple_fifo which is the repository, https://github.com/intel/systemc-compiler/tree/main/systemc/examples/sysc/simple_fifo.
But I am getting an error stating " Static record is not supported yet "

fatal error: ScTool internal fatal error : Static record is not supported yet
1273: static const sc_event none;
1273: ^
1273: ----------------------------------------------------------------
1273: SystemC-to-Verilog trasnlation, ERROR
1273: ----------------------------------------------------------------
1273: 1 error generated.
1273: Error while processing /home/spoorthy/work/systemc-compiler/build/icsc/designs/Simple/Simple.sctool.cpp.
1273: Top-level module is top
2/2 Test #1273: Simple_SYN .......................***Failed 2.14 sec

The following tests passed:
Simple_BUILD

50% tests passed, 1 tests failed out of 2

I want to know how to synthesize the module with the primitive channel. Can you please guide me with this?

Clang/LLVM 13 support

Some tests not passed

Record copy constructor not supported yet

Operation

build.sh removal intentional ?

A build.sh was added recently and announced in commit log.
Then a few weeks later is was removed, unannounced.
Was the removal intentional ?

Removal commit:
c4dfc80

Cmake build conflicts with local LLVM and Protobuf installations

Hi,
this is a very nice work and the installation works well but the FIND_PACKAGE functions from CMAKE will first look for the global LLVM and Protobuf installation. Maybe a set for SYSTEM_PREFIX_PATH to ICSC_HOME could fix this

Cheers

Assertion signal stable value

Hello,
I am trying to integrate your project in my Systemc-UVM testbench.
I have run into few things that are missing for me, or I dont know how to write them.

For example SVA assertion like this one, which is a quite common rule, that other signals should not change while valid is high and ready low.
AWVALID & ~AWREADY|=>$stable({AWADDR,AWID,AWLEN,AWSIZE,AWCACHE,AWSIZE})

I didn't managed to implement it without adding additional code to the testbench, I tried this.
SCT_ASSERT(sigs->mem_valid & !sigs->mem_ready , SCT_TIME(0), sigs->mem_ready, sigs->mem_addr.value_changed_event());

This should work, but I have a problem that the mem_ready is not getting set in the same delta cycle as mem_addr.
Meaning that when mem_addr changes state, mem_ready is still 0, until few delta cycles later.
In this case mem_ready is driven by verilated RTL, and mem_addr and mem_valid are driven by UVM driver.

UVM_INFO nmi/nmi_monitor.cpp(86) @ 50 ns: env.nmi_agent_master.mon [READY: ] 0 Addr 3 Valid: 1 RData: 0 WData: 1021 wstrb: 15 instr: 0 delta count: 146
UVM_INFO nmi/nmi_monitor.cpp(86) @ 50 ns: env.nmi_agent_master.mon [READY: ] 0 Addr 3 Valid: 1 RData: 0 WData: 1021 wstrb: 15 instr: 0 delta count: 147
UVM_INFO nmi/nmi_monitor.cpp(86) @ 50 ns: env.nmi_agent_master.mon [READY: ] 0 Addr 3 Valid: 1 RData: 0 WData: 1021 wstrb: 15 instr: 0 delta count: 148
UVM_INFO nmi/nmi_monitor.cpp(86) @ 50 ns: env.nmi_agent_master.mon [READY: ] 1 Addr 3 Valid: 1 RData: 0 WData: 1021 wstrb: 15 instr: 0 delta count: 149
UVM_INFO nmi/nmi_monitor.cpp(86) @ 50 ns: env.nmi_agent_master.mon [READY: ] 1 Addr 3 Valid: 1 RData: 0 WData: 1021 wstrb: 15 instr: 0 delta count: 150

For example above you can see few delta cycles after mem_addr.value_changed_event() is notified in a process. You can see that mem_ready goes to one in few cycles.

I managed to solve it, by making an additional sc_signal addr_old, that is one cycle behind mem_addr.
SCT_ASSERT(sigs->mem_valid && !sigs->mem_ready , SCT_TIME(1), sigs->mem_addr == *addr_old , sigs->clk->posedge_event());
However this solution requires additional signals, which defeats the purpose of the library in my opinion.

Do you know of a more elegant way of solving it, or would you consider adding feature that would ease this property to the library?
I am willing to implement it, provided some guidance.

Installation and Uninstallation

A very nice work! But I still have two questions.
(1) If I have installed protobuf and llvm before, but not in path $ICSC_HOME, can I skip steps of installating them that written in the install.sh and manual installation guide?
(2) How can I uninstall ICSC?

Problems with building tests

Building tests requires a build done in Debug mode. The instructions do not seem to specify that.
When building the tests after setting Debug mode, it seems that sct_assert.h is not found. Perhaps includes need to update it?

[  8%] Building CXX object tests/const_prop/CMakeFiles/test_const_prop_many_forks_sctool.dir/test_const_prop_many_forks.sctool.cpp.o
In file included from /systemc-compiler/icsc/build/tests/const_prop/test_const_prop_many_forks.sctool.cpp:5:
/systemc-compiler/icsc/tests/const_prop/test_const_prop_many_forks.cpp:13:10: fatal error: sct_assert.h: No such file or directory
   13 | #include <sct_assert.h>
      |          ^~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [tests/const_prop/CMakeFiles/test_const_prop_many_forks_sctool.dir/build.make:63: tests/const_prop/CMakeFiles/test_const_prop_many_forks_sctool.dir/test_const_prop_many_forks.sctool.cpp.o] Error 1

Ambiguous operator <<

Streaming SValue to DiagnosticBuilder is ambiguous between the two functions:

// Diagnostic.h line 1295
template const DiagnosticBuilder & DiagnosticBuilder::operator<<(const T &V) const

// SValue.h line 242
template friend OsT & SValue::operator << (OsT &os, const SValue &val)

Depending on which compiler I use, there is an error to this ambiguity. I have yet to learn if it is the C++ standard or other flags that makes the difference.

My workaround is to patch all code to call SValue::asString() when they stream to the DiagnosticBuilder.

segfault when trying to synthesize

Hello,

I'm trying to convert an existing Open-Source Project to compile it with the ICSC.
I rewrote our test bench for this project and changed the source and header files to be synthesize-able with your tool.

I encountered an error when running the ctest or executing the _sctool directly. while the simulation runs correctly the synthesis throws a Segmentation Fault error.

I tried to identify the error by using the GDB and came to the point in code where the sc_start() gets replaced by the runScElab(__sctool_args_str) for synthesis.

The Segmentation Fault is in the initContext() from libSCTool.so

Do you have any ideas what could possibly be a reason for a segfault here?

Heres the GDB output:

Breakpoint 1, sc_main (argc=1, argv=0x5555555ea030) at /home/marco/Workspace/intel_compiler/icsc/designs/paranut_test/dm_tb.cpp:335
335	    int arg, cfg_help = 0;
(gdb) n
338	    arg = 1;
(gdb) 
339	    while (arg < argc && argv[arg][0] == '-') {
(gdb) 
354	    if (cfg_help) {
(gdb) 
363	    sc_clock clk{"clk", sc_time(CLK_PERIOD, SC_NS)};
(gdb) 
364	    Tb tb("tb");
(gdb) 
365	    tb.clk(clk);
(gdb) s
sc_core::sc_in<bool>::operator() (this=0x7fffffff93b0, interface_=warning: RTTI symbol not found for class 'sc_core::sc_clock'
...) at /home/marco/Workspace/intel_compiler/include/sysc/communication/sc_signal_ports.h:495
495		{ this->bind( interface_ ); }
(gdb) n
sc_main (argc=1, argv=0x5555555ea030) at /home/marco/Workspace/intel_compiler/icsc/designs/paranut_test/dm_tb.cpp:368
368	    sc_start ();
(gdb) s
sc::sctool_start<>() () at /home/marco/Workspace/intel_compiler/include/sc_tool/SCTool.h:36
36	    runScElab(__sctool_args_str);
(gdb) 

Finalize elaboration
Design unity file: /home/marco/Workspace/intel_compiler/icsc/designs/paranut_test/build/DebugModule.sctool.cpp

In file included from /home/marco/Workspace/intel_compiler/icsc/designs/paranut_test/build/DebugModule.sctool.cpp:5:
In file included from /home/marco/Workspace/intel_compiler/icsc/designs/paranut_test/dm_tb.cpp:35:
In file included from /home/marco/Workspace/intel_compiler/icsc/designs/paranut_test/dm.h:39:
/home/marco/Workspace/intel_compiler/icsc/designs/paranut_test/base.h:74:2: warning: "INFO: __SYNTHESIS__ is not set! This is just a ParaNut debug info." [-W#warnings]
#warning "INFO: __SYNTHESIS__ is not set! This is just a ParaNut debug info."
 ^
--------------------------------------------------------------
 Intel Compiler for SystemC (ICSC) version 1.4.38, Aug 20,2022
--------------------------------------------------------------
Top-level module is MDebugModule

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5c7bbcf in sc::ScTraverseConst::initContext() () from /home/marco/Workspace/intel_compiler/lib/libSCTool.so
(gdb) 
Single stepping until exit from function _ZN2sc15ScTraverseConst11initContextEv,
which has no line number information.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.

Clarification of 7.1 Memory wrapper

Hi,

currently I am implementing a simple Cache module intended to be synthesized for a Xilinx Zynq-7000.
I would like to map the register representing the cache's memory to the block ram provided by my FPGA.

The relevant Code Section currently looks like this

class MBankRam : ::sc_core::sc_module {
  sc_uint<32>  ram_[2048];
};

The HLS converts this to

logic [31:0] ram_[2048];
logic [31:0] ram__next[2048];
...

The ICSC Manua 7.1 Memory wrapper mentions a common interface for memory access. However, quite honestly, I have a hard time getting this to work with in code. Can/should this be used in this case?
Is there a dedicated method for implementing registers that should be mapped to block ram?