c-uvm synchronization without DPI

UVM
, , ,
1

Is there an article which talks about c-uvm synchronization (without DPI) in an SoC testbench where CPU is involved.

2

I haven’t come across an article discussing C-UVM synchronization without mentioning the DPI, likely because the DPI is significantly more efficient compared to any other synchronization mechanism.

3

thank you

4

@dave_59
Could you please elaborate on other C/System-Verilog synchronization mechanisms?

Maybe what @abhi98911 meant somehow to a way of communication between the SV code and the C code running on the CPUs present in the SoC?
e.g. handling interrupt, running service routines.

5

yes. thats what i meant. I have edited my original statement to be more clear

6

Could you please provide even more clarification? We need to understand how the CPU is being modeled. Are you referring to a CPU modeled in RTL, a C-model of a CPU, or the CPU itself running the SystemVerilog simulation?

The DPI is specifically designed to integrate C models with SystemVerilog, including UVM.

1 Like
7

CPU is modeled in RTL

8

I would try to elaborate/clarify more as well.

The CPU is an actual RTL (e.g. ARM, RISC-V CPU cores) - a common thing in modern and complex SoC products.
These CPUs are instantiated as RTL blocks, connected to memory subsystem, DRAM controllers, interconnects (coherent in case of multi-core SoC), peripherals, power management units when applicable and clocking units.

System/SoC verification (or firmware/low-level SW) engineers write using C language - a code which will be compiled eventually into assembly code matching the CPU architecture, the assembler code will convert it into a machine code object file (.o).
Next the linker combines all .o files + libraries into an executable binary file.
There might be few additional stages in the flow from converting the C code into the machine code which I forgot/not-aware of.
Eventually this binary image file will be loaded into the memory and would be executed by the CPU as instructions.

The question is how this C code could communicate with the SV/UVM code of the FC/SoC env?

1 Like
9

Yes this is what I was asking for.

10

Because you are using compiled code I can not image to communicate directly with a UVM environment. Bur it is possible to have several different pieces of compiled code you can select for specific applications.

11

This is the problem/question of the author…

Usually you will have several different pieces of compiled code, depends on the testcase or functionality being tested: boot, DRAM initialization, PCIe link-up, fabric configuration, interrupt service routines, etc.

Maybe the communication could be only 1-way from the CPU to the SV/UVM env?

Could TLM2.0 Sockets help in this case?
Does anyone has any experience working with it?

12

This is usually handled in the realm of PSS - Portable test & Stimulus Standard - though technically we (as industry) have been doing this for decades. A rough idea is to dedicate a set of memory locations for such communication and have C/ASM code update that location (usually referred to as a Mailbox, not to be confused with SV native mailboxes). Then, have SV/UVM watch for a non-zero value at the agreed-upon location.

HTH
Srini

2 Likes
13

It might help if you were to explain what kinds of things need to be synchronized. And did you have a specific CPU in mind or is this just a generic question?

14

hi srini,

c/asm updates a agreed upon memory location (which is a memory of the Soc).THis memory location is called as mailbox?

Isnt the SV mailbox(created within the uvm/sv tb) used to pick the data from the agreed upon memory location and give it to the SV/UVM tb.

Not sure why you referred memory location as mailbox. The sv mailbox also is present which is part of the UVM testbench from wjat i have seen.

I have my confusion/clarifications, so just putting it out here.

15

Hi @abhi98911 ,

You can do this by polling and updating a common register/variable which is accessible to both C and UVM env.

Ex :- In UVM TB:
while(poll_c != 1)begin
@(posedge sys_clk);

end

poll_sv = 1;

Same code should be present in C. There you use poll_sv in a while block.

Regards,
Abhinandan

16

@Srini-VerifWorks thanks for your replay, and the idea.

May I ask few follow up questions:

  1. So we basically need to implement a “Mailbox” data structure to be used by both C code and the SV/UVM env…
    Meaning we need to implement a lock/semaphore wrapping accesses to a set of memory locations to be used as the list, right?

  2. Did you use the same “mailbox” for messages transmissions from C code → SV/UVM and SV/UVM–>C code?
    Or you preferred to use 2 separate mailboxes?

  3. Did you had a chance to use this mechanism in a multi-core (multi-CPU) system?

  4. Is there any paper/book on SoC verification you are familiar with introducing this communication/handshake mechanism?

Thanks in advance,
Michael