DPI Interview Questions

An import lets SystemVerilog call a C routine. An export lets C call a SystemVerilog function or task. The import line gives the C name, the directions and the types. The export line names only the SystemVerilog routine, because its own declaration already has the types. Use functions when C computes and returns at once. Use tasks only when C must call an exported task that waits for simulation time.

For an export, the SystemVerilog function declaration already holds the types. Repeating them would give two copies that can drift apart. For an import, the C body is invisible to SystemVerilog, so the import line is the only description it has. The simulator writes a C prototype for both into its generated header.

DPI is a typed function call: you pass values in and get values out, like any C call. VPI is an object model of the design. C code finds signals by name, reads and writes them, and registers callbacks on value changes. Use DPI for reference models and helper code. Use VPI for tools such as debuggers, waveform dumpers or coverage readers that must walk the hierarchy.

Pass it in. The monitor samples the register and gives it to the import as an argument. If C must ask for it in the middle of a call, export a small getter function and make the import context. Avoid hierarchical lookups from C: they hide what the model depends on, and they break when the hierarchy changes.

No. Class methods cannot be exported, because objects do not exist when the design is elaborated. Export a function in a module or package instead. Keep the objects in a table on the SystemVerilog side, and pass C an index or an ID. The exported function looks the object up and calls its method.

With Verilator, you list the .c or .cpp files on the command line. They are compiled and linked into the one simulation binary. Many event-driven simulators instead load a shared library at run time, named with a switch such as -sv_lib. Either way, the C must use C linkage, so C++ files need extern "C".

A context import gets the calling scope. So C may call exports, use svGetScope and use VPI. The simulator must record that scope and assume C may change SystemVerilog state. A pure function promises its result depends only on its arguments. So the simulator may skip or reuse calls, though it does not have to. A stateful model is never pure: use a plain import, and context only if it calls back.

On each call, the simulator records the calling scope so C can ask for it. C may also call exports that change SystemVerilog variables. So the simulator cannot keep values cached across the call. A plain import promises neither, so the call can be cheaper.

Arguments keep the import plain and the data flow visible. C cannot read anything the testbench did not hand it. Getters need a context import and hide the dependency inside C. They also run on every call unless C caches them. Pass configuration once, at model creation or reset, and keep callbacks for real events such as reporting an error.

The other tool may skip a call whose result looks unused, or reuse an earlier result for the same arguments. Then the model misses an update, and its sequence numbers drift from the DUT. Nothing in your passing runs proves the declaration is safe. Review imports for pure on any function with side effects.

Keep every import in one package, so a reviewer sees all declarations together. Allow pure only for functions that are clearly mathematical, such as a CRC of the arguments. Run the regression on a second simulator when the project has one, because skipped calls show up there first.

C itself cannot let simulation time pass. The simple way is to let SystemVerilog wait for ready, then call C, which stays untimed. The standard also allows a context import task whose C calls an exported task that waits. That thread then sleeps inside the export while the rest of the simulation runs. Verilator 5.052 rejects timing controls in exported tasks, so there you must use the first way.

The wait itself, such as @(posedge clk), can only live in a task, because functions may not contain timing controls. A function cannot call a task. So the chain from SystemVerilog through C and back must be task, task, task. The import must also be context, because it calls an export.

The exported task returns 1 to C instead of 0, which means the thread was disabled. C must stop at once, free what it holds and call svAckDisabledState. Then the C task returns 1 to the simulator. C must not call any more exports in that state.

C carries on as if the wait finished. It may call more exports for a thread that no longer exists, which the standard does not allow. Buffers it allocated for the item are never freed. The test can end with the model one item ahead of the testbench.

An untimed model is a pure prediction step. It is portable, easy to test alone, and the testbench decides when to call it. A timed model owns its own sequence, which suits legacy C test programs. But it needs context task imports, careful disable handling and reentrant C code. Choose the untimed model unless existing C already drives the flow.

Save the caller with svGetScope() as the first step. Switch to the logger with svSetScope, using a scope from svGetScopeFromName("tb.logger"), and call the log export. Then restore the saved scope before calling sv_accept. An export always runs in the current scope, and svSetScope changes it for the rest of the call. Look the name up once and check it for null.

The context of an import is where it is declared, so a package import has the package as its scope. Verilator 5.052 reported the calling instances, tb.u0 and tb.u1, in our probe. Code that relies on that may break on another simulator. Declare a context import inside the module whose exports it calls.

Attach it to the scope. svPutUserData(scope, key, ptr) stores a pointer for that instance, and svGetUserData(scope, key) gets it back. The key is the address of a static variable, so two libraries never collide. Create the state on the first call, when the lookup returns null.

Scope data belongs to a module, interface or program instance. A UVM scoreboard is a class object, and all its calls come from the same import scope. So scope data cannot tell two scoreboards apart. A chandle from model_new() belongs to the object that holds it. Use the chandle for class-based benches.

The lookup returns null. If C passes that to svSetScope and calls an export, the export has no scope. Verilator 5.052 stops the run with a "scope wasn't set" error. Check every lookup, and return an error code the testbench reports.

Frame #0 is the C model, model_predict, with h=0x0. Frame #2 shows the scoreboard's write made the call through the DPI wrapper. So the scoreboard's chandle was never set: nothing called model_new before the first prediction. The empty log is stdout buffering, because the process died before it flushed. Fix the build order, and make the C return a status for a null handle.

When output goes to a file or a pipe, the C library collects it in a buffer. It writes the buffer in large blocks. A segmentation fault kills the process before that buffer is flushed. Our probe showed the line once $fflush() ran before the risky call. Running under gdb also avoids guessing, because it stops at the crash.

Build the C model with -g, so frames show file and line. Rerun the failing seed under gdb with run then bt. Or allow core files with ulimit -c unlimited, and open the core with gdb ./obj/Vtb core. Read frame #0 first, then walk down to the first frame in your own code.

Suspect undefined behaviour in the C: an uninitialised variable, a stale pointer or a read past an array. It shows up only with certain compilers, flags or memory layouts. Reproduce with the farm's exact build flags and seed, then run an AddressSanitizer build. It reports the bad access where it happens, not where it later crashes.

A status lets SystemVerilog report the error through the normal error path, with the time, the transaction and the test name. The run then ends cleanly, and its final blocks and end-of-test reports still run. An abort kills the process at once and skips all of that. So C returns a status, and SystemVerilog decides how bad it is.

The crossing is not the cost here: Verilator turns an import into a direct C++ call. The batched version still calls svGetArrElemPtr1 once per byte, and at -O0 each call does full bounds checks. At -O2 both versions take the same time, so the CRC loop itself dominates. Take one pointer with svGetArrayPtr when it is not null, and build the model optimised. Profile on the sign-off simulator before changing the interface again.

Verilator compiles the whole testbench to C++. An import becomes a small generated wrapper that converts the arguments and calls your function in the same binary. Our backtrace shows that wrapper, Vdpiimwrap_model_predict, as one frame. There is no interpreter between the two sides.

In our -O0 probe, a million calls took 46 ms with logic [511:0], 30 ms with bit [511:0] and 50 ms with a short string. A four-state vector carries two words for every 32 bits, so there is more to convert. A string may need a conversion to const char*. In a hot path, prefer two-state types and numbers.

Run the simulator's profiler, or perf on a compiled binary, and read the top functions. Count the calls into C per test. Then time the same calls with an empty C body. That time is the crossing, and the rest is the model's own work.

The call count now grows with simulated cycles, not with transactions. A long idle period costs as much as busy traffic. Call the model only when the protocol says a transfer happened, such as valid && ready at the edge.

Avoid DPI for work SystemVerilog already does well: random stimulus, waiting for time, small checks and text formatting. C rand() ignores the SystemVerilog seed and random stability, so a failing seed may not reproduce. DPI also adds a second build and debug flow, and a C bug crashes the whole simulation. Use it when a trusted model already exists in C, C++ or Python, or the algorithm is heavy.

C rand() is one stream shared by every caller in the process. Its next value depends on how many calls came before, from any thread or any model. Add one call in another component, and every later value moves. SystemVerilog avoids this by giving each thread and object its own generator.

Give each model its own generator, such as a std::mt19937 inside the model struct. Seed it from a value SystemVerilog passes at creation, taken with $urandom. Then the SystemVerilog seed controls the model, and each model has its own stream.

A vector file is simple: no shared build, and the model runs once. But the stimulus is fixed in advance, so the test cannot react to random choices, backpressure or resets. DPI keeps the model in the loop for every transaction. Use files for fixed directed suites, and DPI for constrained-random benches.

The exception tries to unwind through simulator code that does not expect it. The standard calls that undefined behaviour. In practice the process usually stops in std::terminate with no test report. Wrap every import body in try/catch and return a status instead.

Call the model when the input monitor reports an accepted request, using that request's fields. Push the prediction into an expected queue. When the output monitor reports a response, pop the oldest prediction and compare. Never predict from the response itself: if the DUT corrupts the echoed address, the model agrees with the bug. Create the handle in the constructor or build phase, and check the queue is empty at the end.

A single queue would compare the wrong pairs. Store predictions in an associative array keyed by ID, each holding a queue for repeated IDs. On a response, look up its ID, pop the oldest prediction for it, and compare. At the end, every queue must be empty.

Wrap it behind a thin, versioned DPI layer owned by verification: transaction in, predicted transactions out, one handle per instance, plus reset. Feed it from monitors, never drivers, so it predicts from what the DUT actually received. Agree on where the model is untimed, such as ordering between independent streams, and compare there by key rather than by cycle.

A C model can be the architecture team's own code, so verification checks against an independent source. It costs a second language, a boundary and a second debug flow. A SystemVerilog model debugs in one tool and sees four-state values. Choose C when the model already exists or the algorithm is heavy; otherwise keep it in SystemVerilog.

Break something on purpose and watch it fail. Corrupt one DUT output with a force, or add a bug in a scratch copy of the RTL. Then check that the scoreboard reports exactly the expected mismatch. Also count predictions and responses: equal counts show the model saw every transaction.

DPI reaches only C, so a C bridge embeds CPython in the simulation. Start the interpreter once, import the module once, and keep the function object. Copy each transaction into Python objects, and check every conversion back. Turn every Python exception into a status code. Give the model an explicit reset, because importing a module again returns the cached copy with its old state.

Python runs a module's top-level code only on the first import. It then stores the module in sys.modules, and every later import returns that object. So total keeps its value. A reset must be a function the model provides.

The standard defines DPI only between SystemVerilog and C. So a small C bridge starts the Python interpreter, calls the model and converts arguments and results. The bridge must catch every Python exception and turn it into a status code, because nothing may unwind into the simulator. Pass a whole packet per call, not one byte, because each call into Python is much slower than a C call.

In our probe, 640000 per-byte calls into Python took 32 ms. 10000 per-packet calls took 6 ms for the same bytes. Each call crosses into the interpreter and builds Python objects, so fewer, larger calls win. The real cost is usually the Python work inside the model, so measure before redesigning.

Start CPython with an isolated configuration, so environment variables and user site packages are ignored. Put only the model's own directory on sys.path. Pin the interpreter version the bridge was built against, and print the model version at start of test. Then a failure on one machine can be reproduced on another.

By default, Python installs its own handler for SIGINT. The handler only sets a flag that Python checks while it runs Python code. While the simulator runs outside Python, nobody checks that flag. Set install_signal_handlers = 0, so Ctrl-C stays with the simulator.

First agree the C interface with the model owners: transaction in, prediction out, a handle per instance, reset, delete and status codes. Put every import in one package behind a thin wrapper that verification owns. A predictor calls the model for each accepted input transaction and sends predictions to the scoreboard. Reset the model with the DUT, and fail on predictions left at the end. Sign off only after a known DUT bug makes the scoreboard fail.

The import lines are the contract with C. In one place, a reviewer checks every type, pure and context together. A model change edits one file, and the build fails at once wherever a caller disagrees. It also gives one place to swap in a stub model for unit tests.

Let time stay in the bench. The model predicts once per accepted input, in zero time, and the prediction waits in the scoreboard. The comparison happens when the output monitor reports, so latency does not matter. Where the model and the DUT may legally order things differently, compare by key, not by cycle.

A test with a known DUT bug must fail in the scoreboard with the right message. Prediction and response counts must match in every passing test, with nothing left at the end. A sanitizer build of the C must run clean on a subset. The model version must be printed in every log.

The scoreboard does not, because model and DUT agree. Catch it with checks that someone else writes straight from the spec. Use assertions, directed tests with hand-worked values, and spec reviews of the unclear lines. Log the question to the spec owner, and fix both sides.

It prints 4, not 10. The export runs inside the outer call and calls c_parse again for the inner packet. That nested call writes the one static cur_len, so the outer call returns the inner length. A static is safe only if nothing can re-enter before the call finishes. A callback can re-enter, and so can a context task that waits in an exported task. Keep in-progress state in local variables or a per-call struct.

An imported function returns in zero time and cannot block. So the scheduler never switches threads while it runs. The second thread enters only after the first call has returned. The danger starts only when C calls back into SystemVerilog, or when an imported task suspends.

A local lasts for one call, so re-entry cannot harm it. A struct behind a chandle lasts as long as the model, and each instance owns its own. A static lasts for the whole simulation and is shared by every caller and every instance. Use locals for work in progress, the struct for model state, and statics almost never.

Agent A enters C and suspends inside the export. While it waits, agent B calls the same C function and runs it from the top. Both calls are now live in C at once. Any static they touch is shared, so the C code must be reentrant.

Agent B's call comes from the same OS thread that still holds the lock for agent A. Locking a std::mutex you already own is undefined, and usually blocks forever. Agent A can never resume, because the simulator thread is now stuck. Remove the static instead.

Each side frees only what it allocated. Strings, arrays and vectors that SystemVerilog passes in are borrowed for the call. C never frees them or keeps pointers to them. A string C returns is still C's memory. The simulator copies it and never frees it, so a fresh malloc per call leaks. Keep result buffers inside the model, and give a chandle model a delete call that SystemVerilog makes once.

C cannot know how the simulator made that memory. It may come from a pool, the stack, a temporary copy, or a C++ object. Only the allocator that made a block may free it. A clear rule on each side makes both implementations free to change.

The fresh malloc leaks on every call. The static buffer does not leak, but every model shares it and the next call overwrites it. A buffer inside the model struct is owned by that model and freed with it. Choose the model buffer.

The chandle still holds the old address, so C writes into freed memory. That may work, return garbage or crash much later. C cannot tell a freed pointer from a live one. Set the handle to null right after delete, and have SystemVerilog check it before every call.

Run a nightly subset with AddressSanitizer: build the C model and the simulation with -fsanitize=address. It reports a use-after-free or a wild read at the line that does it. Also keep a live-model counter in C, and check at the end of every test that it is zero.

It prints 4091, not -5. A packed vector such as bit signed [11:0] crosses as an array of 32-bit svBitVecVal words. The 12 bits sit at the bottom of word 0, and nothing copies the sign bit upward. So C reads 0xFFB as a positive number. Sign-extend from bit 11 in C, or use shortint or int, which cross as C short and int with their sign.

A packed vector can have any width. So the standard gives every vector one form: an array of 32-bit words, passed by reference. byte, int and longint have a fixed size, so each has its own C type and travels by value. The generated header shows which form each argument got.

Each 32 bits of a logic vector cross as one svLogicVecVal with two words. A bval bit of 0 means the bit is known, and aval holds its value. A bval bit of 1 means unknown: aval 1 is x and aval 0 is z. A checker that rejects unknowns must test bval, not aval.

Test the C function on its own, with a small C test that builds svLogicVecVal values with bval bits set. Run the DPI x tests on a four-state simulator, if the project has one. Where unknowns matter in the design, also carry an explicit valid mask, which works on both kinds of simulator.

A longint crosses by value as a C long long, ready to use. A bit [63:0] crosses as two svBitVecVal words. Word 0 holds bits 31:0 and word 1 holds bits 63:32, so C must join them with a shift. Prefer longint for numbers, and vectors for fields wider than 64 bits.

C receives an svOpenArrayHandle, not a byte pointer. Check count against svSize, and find the direction from svLeft and svRight. Then step from the left bound and read each element by its SystemVerilog index with svGetArrElemPtr1. Check each pointer for null. Never assume index 0 exists or comes first: in pkt[63:0] the first byte written is pkt[63].

The simulator's array may have any bounds, packed elements, four-state values or a layout C does not know. The handle hides that layout behind query and access functions. svGetArrayPtr returns a direct pointer only when the layout matches C, and null otherwise.

A sized formal crosses as a plain pointer; the generated header gave const unsigned char* d. Every actual must then have that exact size. An open formal crosses as a handle, so one C function serves any length and any bounds. Use the sized form only when the length is fixed by the protocol.

C cannot grow a SystemVerilog array. The caller passes an output open array big enough for the longest response. C writes up to svSize elements and returns the count it used. If the response does not fit, C returns an error status instead of writing past the end.

The pointer is valid only during the call that produced it. Afterwards, the simulator may move, reuse or free that storage. The next read can return another packet's data or crash. Copy the bytes into C-owned storage before the call returns.

It prints 2, not 3. A SystemVerilog string cannot hold a zero byte, so the 0x00 is dropped as the string is built. Even if it got through, C's strlen stops at the first zero. A string crosses as a borrowed const char* and is for text, such as names and file paths. Send binary data as a byte array with a count.

The standard says so: a string never contains the 0 character, and writing 0 into one character is ignored. That keeps it compatible with C strings, which end at the first zero.

A string argument reaches C as a pointer to memory the simulator owns, valid only while the call runs. After the call returns, the simulator may reuse or free that memory, so the stored pointer can point at anything. Copy the text into storage the C side owns during the call.

The copy gets the same address, so both objects drive one C model. An update through either is seen by both. If the copy needs its own state, call a C clone function that allocates a new struct. Then decide which object deletes which model.

A chandle always has the size of a pointer on the machine that runs the simulation. The language only lets you assign it, compare it with null and pass it to C. That stops SystemVerilog code from doing arithmetic on it or inventing values. A longint would work by accident on a 64-bit host and offer none of those guarantees.