Mixed language single-kernel SC/SV/VHDL

[amal-khailtash]

Are there any flows where I can mix SystemC with SystemVerilog/VHDL in a single kernel (vendor compile)? Use cases might be SystemC (UVM-SC) on top or SystemVerilog (UVM) on top.

The current mixed language example assumes SV/VHDL only.

[amal-khailtash]

Basically, what I am looking for is how to do the equivalent simple_sc_verilog and also simple_sv_sc version using SoCMake.

[Risto97]

Hello @amal-khailtash ,

Thank you for taking an interest in SoCMake.

Yes, this is possible, and there was already a more complete example here: https://github.com/HEP-SoC/apb_crc_uvm_socmake/tree/master/sc-uvm
It includes a full SystemC-UVM testbench (missing CRAVE for constrained random, and functional coverage, which is also possible)

I ported quickly the example you suggested from VeriSC here (https://github.com/HEP-SoC/SoCMake/tree/develop/examples/simple_sc_sv).

Note that there are some limitations currently, it is only possible to have SystemC on top, SV/Verilog as DUT and only with Verilator.

I have in the roadmap to implement also what you suggested, that is:

1. SystemC on top with commercial simulators (only Verilator supported now)
2. SystemVerilog on top, SC as dut with commercial simulators (For Verilator this would not be possible)
3. SystemC on top, VHDL as dut, for commercial simulators
4. Possible mix of hierarchy levels SC-SV-SC... SV-SC-SV with commercial simulators

Which simulator are you interested in using for SV, Verilog, and VHDL? Would Verilator work for now?

To give you a short history of the project.
SoCMake was started for this exact purpose, doing SystemC verification. VeriSC was the initial attempt at the topic and was since archived in favour of SoCMake.

After a while, I realized that SoCMake could do much more than SystemC verification, so I started developing it as a generic HW/SW build system.
Unfortunately, I started prioritizing other aspects of the build system, and the SystemC verification features from VeriSC were not fully ported, hence no support for SC-SV simulation with commercial simulators.

I do plan to bring these features back into SoCMake in the next months, however, I am limited with time, and I am trying to polish core aspects (IP library API) for the 1.0.0 release.

If you are interested in helping with the development, it would be very appreciated.
It would also be helpful if you could share your use case.

[amal-khailtash]

Hello @Risto97, thanks for pointing to that depo as well as porting the example.

Unfortunately, my use case does not allow Verilator. We mainly use Synopsys VCS and sometime Questasim as well, rarely Xcelium.

We have a mix of testbenches. Mostly UVM-SV or UVM-SC on top. As we use HLS for some designs, our DUT can be either SC or SV. The DUT SC would have an equivalent SV (with possibly some port adaptation). As we are mainly using VCS, we are thinking of moving away from SC TB, because of a limitation with VCS that they call Donuts. VCS does not support crossing SC->SV->SC. And this prevents us from replacing our lower-level SC designs with SV. So, we might need to go to SV (TB) -> SV (DUT) -> SC -> SV. We do not need to worry about this now, but the idea would be to use mixed-language single-kernel compile under VCS and allow mix and match top/bottom blocks if possible. We do not use VHDL much, unless there is a vendor IP we need to use.

It is great that you separated the build flow from actual HLV concerns.

We mostly use Makefiles and our custom build scripts, and I was looking to implement this with CMake as I find it is modularized, extendable. We also have a mix of C/C++ and DPI code that also needs to be compiled and I thought CMake is a good choice.

Thinking there must be some extension out there, I came across this repo.

I can certainly help time permitting. My CMake knowledge is rusty and not extensive.

[Risto97]

Hello @amal-khailtash ,

Thank you for sharing this information.

Yes, I remember some limitations with VCS.
However the support will come gradually, I will first support SV-SC and SC-SV, the other combination might or might not come for free after that.

There is one thing that I am trying to do that makes it a bit more difficult, and that is avoiding to use of vendor tools that wrap GCC calls to compile and link C++ executables.
Instead of using tools such as syscan, xmsc, etc..., I am trying as much as possible to understand how to use GCC/Clang toolchains directly.
This allows for a bit more reusability between the support for different tools, and better CMake integration, but also makes it more difficult, as sometimes some reverse engineering is needed.

What you are trying to do, sounds very similar to what I wanted when I started the project, and I was in a similar situation picking which language/build system to base it on.
In the end, I think CMake is a good platform for this solution and I was also surprised there was no similar project implementing this.
From my experience, Makefiles do not scale well for bigger projects, as there is a lack of reusability, and would have to reimplement a lot of features already present in CMake.

For DPI-C, this is a feature SoCMake supports, you can take a look at how it is loaded into the SV-UVM testbench.
First, the DPI library is compiled as a shared (or static) library here: https://github.com/Risto97/apb_crc_uvm_socmake/blob/master/sv-uvm/crc_dpi/CMakeLists.txt, note also how easy it is to fetch an external C++ library with CPM and link it in a CMake project.
Later in SoCMake, linking the DPI library into the SV testbench can be done using ip_link() function: https://github.com/Risto97/apb_crc_uvm_socmake/blob/master/sv-uvm/CMakeLists.txt#L36.
There is a similar example also for VHDL UVVM here: https://github.com/HEP-SoC/UVVM_SoCMake/blob/master/examples/apb_crc/CMakeLists.txt

I hope to get work restarted on this in the next weeks, and if you are interested you can give it a try and give me feedback. This would already be a great contribution and help for me.

[amal-khailtash]

To be able to used mixed language simulation, in VCS, one needs to use syscan at least on a dummy file. Whether one compiles SC files with g++ outside of VCS or not. Using vendor compile commands (VCS: syscan), (Questa: sccom), ... allows them to create wrappers and translations between SC and SV port types.

There are strict dependence on specific g++ versions for both VCS and Questa if one wants to use mixed, single-kernel simulation.

I can certainly help with reviews or implementation.

[Risto97]

Hello @amal-khailtash ,

I had a little bit of time to work on this.
Yes, you are right, the vendor tools cannot be fully avoided.

I was playing a bit with Questa: sccom, scgenmod commands. Although I could manage to compile the object files with G++, and to link them, by looking at how they invoke g++ when passed -vv flag.
These commands do more than just invoke g++, and it's mostly updating the simulation database, for vsim to later find compiled modules.
I had some success by passing -nocc flag during sccom compilation, where only the database is updated but object files are not compiled. However this flag does not work for -link, when the object files are linked into systemc.so library.

To start the conversation, I made a "naive" implementation of SystemC-Verilog mixed language simulation.
I execute sccom, and do not try to compile object files with g++, for now.
The plan is to get all the simulators working with a simple example first, utilizing vendor tools, and then later try to extract similarities between them, and hopefully replace SystemC compilation with g++.

Here is an example that I prepared for testing what is currently supported:

SoCMake/examples/simple_mixed_language_sc_vlog/CMakeLists.txt

Lines 85 to 138 in b7531fb

	################################################
	############ SYSTEMC ON TOP MODELSIM ###########
	################################################
	if(SCENARIO STREQUAL "MGC_SC_VLOG")
	add_ip(counters)
	ip_sources(counters VERILOG
	./counter1.v
	./counter2.v
	./counters.v
	)
	modelsim_scgenmod(counters)
	add_ip(test_counters)
	ip_sources(test_counters SYSTEMC
	./test_counters.cpp
	HEADERS
	./test_counters.h
	)
	ip_link(test_counters counters)
	modelsim(${IP})
	endif()
	################################################
	############ VERILOG ON TOP MODELSIM ###########
	################################################
	if(SCENARIO STREQUAL "MGC_VLOG_SC")
	add_ip(counters)
	ip_sources(counters SYSTEMC
	./counters.cpp
	HEADERS
	./counter1.h
	./counter2.h
	./counters.h
	)
	add_ip(test_counters)
	ip_sources(test_counters VERILOG
	./test_counters.v
	)
	ip_link(test_counters counters)
	modelsim(${IP})
	endif()

This example currently supports following scenarios:

• OSCI_SC: Open-Source SystemC only tesbench, compiled with GCC
• VERILATOR_SC_VLOG: OSCI SystemC on top, and verilated Verilog as submodule
• MGC_SC: Pure SystemC using Questa's shipped SystemC shared library
• MGC_SC_VLOG: SystemC on top, verilog as submodule using Questa sccom and scgenmod
• MGC_VLOG_SC: Verilog on top and SystemC as submodule, using Questa
• MGC_VLOG: Pure verilog using Questa

To run the simulation, execute the following steps:

git clone -b modelsim_sc_sv https://github.com/HEP-SoC/SoCMake.git
cd SoCMake/examples/simple_mixed_language_sc_vlog
mkdir build && cd build
cmake -DSCENARIO=<SCENARIO-NAME> ../
make help_all
make <run-target-name>

---

I would be interested in hearing your feedback on this flow.
I see that you have an idea of using a dummy file to trick the simulator to generate databases to use g++ independently.
Would you be interested in discussing this over a call, it would be easier for me to understand your use case, and hopefully we can steer the implementation in the right direction.

[amal-khailtash]

Hi @Risto97, I did try a few of your scenarios. Some passed and some failed. I can give you more feedback once I try them all and resolve my compile/link issues with gcc/libraries incompatibilities.

You can add me to your network on LinkedIn (on my github profile) and we can swap contacts. I can definitely give you more feedback.

[amal-khailtash]

Here are a few general recommendations:

1. In the mixed language example, it would be good if you could separate the design and test into their own directories. Also, have separate directories for different implementation (SC vs SV).
2. I am not familiar with the decisions that made into the organization of CMake targets. Normally we try to separate the DUT compile from TB compile for one: different teams handle those and two: faster more efficient compile (compile DUT once and TB as it gets developed).
3. I would separate SCENARIO into SIMULATOR (OSCI, MGC, VERILATOR, VCS, ...) and then topology differently. I will let users be able to pick and choose the underlying implementation: SC vs SV, ... Logistics need to be hashed out.
4. Separating by IP in the build directory might be useful, but also allowing users to compile into different libraries would be great too.
5. Other that Topology (SC on top or SV on top), I would use of SystemVerilog configuration to select the implementation of the different lower level blocks and switch SC vs SV based on SV configuration. Or otherwise allow the selection in CMAKE.

[amal-khailtash]

6. Provide a way to run simulation using interactive GUI.

When I build for OSCI_SC, I do not see any build targets for compile/sim:

Target                      Description
----------------------------------------------------------
graphviz                    Generate a build graph with graphviz
help_ips                    Print IPs help
help_targets                Print targets help
help                        CMake native help
----------------------------------------------------------

So, I just ran make, but SOCMake assumes SystemC library are available here!

apb_crc_uvm_socmake/sc-uvm/build/systemc-build/src/systemc-build/src/libsystemc.so.2.3.4

7. Would be great if I could specify SYSTEMC_HOME for include/library. I am not sure how to override the above path.
8. I have also seen some usage of CONAN2 for dependency management. Maybe we can use it for SystemC and other dependencies as well.

[amal-khailtash]

10. It would be great if we allow users to bring in SOCMake CMakefiles in a way that does not make assumptions on directory structure and let users bring in SOCMake easily into their project.