Communication from C to SV and vice versa

UVM
1

Hi,

I would like to know if there are any framework/packages/design patterns to handle communication from C world (code running on the processor side) with the classical UVM TB in SV and vice versa.

2

In reply to shatrish:

The blunt answer is SystemVerilog has a DPI that allows interaction between C code running on the same machine as the host simulation.

https://verificationacademy.com/forums/systemverilog/starting-dpi#reply-90358

For a better answer, you need to be a little more specific. Processors do not run C code, they run machine code instructions. Is your processor a high-level model, or written in RTL? What kind of communication are you looking for?

3

In reply to dave_59:

In reply to shatrish:
The blunt answer is SystemVerilog has a DPI that allows interaction between C code running on the same machine as the host simulation.
Starting with DPI - SystemVerilog - Verification Academy
For a better answer, you need to be a little more specific. Processors do not run C code, they run machine code instructions. Is your processor a high-level model, or written in RTL? What kind of communication are you looking for?

Probably, I should have given more background on this …

I am looking for any well known design patterns for C-SV and SV-C communication.
By “C”, I mean C code that is compiled for, say, ARM processor. Also, “C” is used more generically. I could be assembly (ASM) too.
By “SV”, this is typically the SV testbench code.
This is quite common in a SoC verification environment where the communication has to be established between C world and SV world for synchronous execution of test intent.
For example, there are many scenarios in SoC verification where multiple times hand-off has to be done from C to SV and SV to C. I am aware of the DPI part and this question is not related to that.

I understand that, there are several ways to do it and we have done it ourself in our projects but if there is a known design pattern or an existing framework in open source then we would like to go that route instead of creating home grown methodology.

4

This could be better handle by allocating space in memory to be used at porthole by your testbench. ARM core will write and read to that memoery location. SV code will also read or write memory location through specific driver and monitor