DPI is SystemVerilog's standard mechanism for calling C functions from SV code and calling SV functions back from C, with plain function-call syntax on both sides.
When would I use this? When the team already has a tested C or C++ model, such as a CRC, a codec or an instruction-set simulator, and the testbench should call it rather than copy it. If your checks are plain SystemVerilog, you can skip this topic. PacketFIFO needs none of it: its check byte is a one-line XOR.
Direction | SV construct | C side |
|---|---|---|
SV calls C |
| Plain C function in a shared object |
C calls SV |
| Exported SV function, called with a valid scope |
Lesson | What it covers | Path |
|---|---|---|
Import syntax, pure and context qualifiers, type mapping, checksum round trip. | Optional | |
Exports, scope handles, and the event callback pattern. | Optional | |
Open arrays, packed structs, strings, and ownership rules. | Optional | |
Wrapper classes, versioning, build flow, threading, and debug. | Optional |
Required is the core first pass for this part's goal, Recommended is for most learners, and Optional is reference, specialist or revision material. The whole topic is Optional: skip it unless your project has C code, and if it does, read the imports lesson first.
No. The C implementation is the single source of truth. Import it through DPI-C and keep the testbench free of a second copy that can drift.