[Sim][SimToSv] DPI-C Semantic preserving sim.func.dpi and sim.func.dpi.call by pscabot · Pull Request #9977 · llvm/circt

pscabot · 2026-03-19T11:54:19Z

Introduce DPIDirection enum (Input, Output, InOut, Return, Ref) and
DPIFunctionType, a first-class MLIR type that bundles port name, type,
and direction. DPIFuncOp now stores DPIFunctionType + FunctionType
instead of hw::ModuleType + per_argument_attrs.

SimTypes: DPIArgumentstruct, DPIFunctionTypeStorage with cached index
arrays. Shared helpers (stringifyDPIDirectionKeyword,
parseDPIDirectionKeyword, isCallOperandDir) and
DPIModuleType::verify() for reuse by downstream dialects.
SimOps: DPIFuncOp parser/printer with keyword syntax
(input/output/inout/return/ref). Verifier adds sim-specific
checks (ref→llvm.ptr, function_type consistency).
LowerDPIFunc: Iterates DPIFunctionType ports directly.
FIRRTL LowerDPI: Builds DPIModuleType; dedup keyed on
{StringAttr, DPIModuleType}.
SimDPI.md: Elaborates design choices for the new semantics.

AI-Assisted-by: GitHub Copilot CLI with GPT-5.4 and Claude Opus 4.6

This is the first of a 2 PR series introducing full sematic preserving DPI calls from SystemVerilog through Moore to Sim.

uenoku

The proposal makes sense to me. Thank you for working on this! One high-level comment is can you consider introducing a type for dpi function that correctly capture sim.func.explicitly_returned and byref as more structured way instead of putting on operations? I admit I'm the one that abused ModuleType but would be fantastic if we can use this opportunity to clean up.

pscabot · 2026-03-19T17:30:15Z

The proposal makes sense to me. Thank you for working on this! One high-level comment is can you consider introducing a type for dpi function that correctly capture sim.func.explicitly_returned and byref as more structured way instead of putting on operations? I admit I'm the one that abused ModuleType but would be fantastic if we can use this opportunity to clean up.

So, departing from the ModuleType is certainly an option. I considered it but it seemed a bit too invasive. I will try to do it.

uenoku · 2026-03-19T18:24:03Z

Thanks, that would be really great!

Introduce DPIDirection enum (Input, Output, InOut, Return, Ref) and DPIModuleType, a first-class MLIR type that bundles port name, type, and direction. DPIFuncOp now stores DPIModuleType + FunctionType instead of hw::ModuleType + per_argument_attrs. - SimTypes: DPIPort struct, DPIModuleTypeStorage with cached index arrays. Shared helpers (stringifyDPIDirectionKeyword, parseDPIDirectionKeyword, isCallOperandDir) and DPIModuleType::verify() for reuse by downstream dialects. - SimOps: DPIFuncOp parser/printer with keyword syntax (input/output/inout/return/ref). Verifier adds sim-specific checks (ref→llvm.ptr, function_type consistency). - LowerDPIFunc: Iterates DPIModuleType ports directly. - SimToSV: Uses getHWModuleType() at conversion boundary. - FIRRTL LowerDPI: Builds DPIModuleType; dedup keyed on {StringAttr, DPIModuleType}. - SimDPI.md: Elaborates design choices for the new semantics.

pscabot · 2026-03-24T15:23:52Z

Thanks, that would be really great!

OK. So it is done. Indeed more invasive but the semantics are much better

pscabot · 2026-03-30T12:40:16Z

Thanks, that would be really great!

@uenoku Hi, are you planning to review this PR? Is there anything else I should do? Is there anyone else I should contact somehow? I hope I am not being too bold, just noticed there wasn't any movement :-). Thanks _/||\_

uenoku

Generally looks good to me. Sorry for delay.

uenoku · 2026-03-24T18:58:55Z

integration_test/arcilator/JIT/dpi.mlir

 // CHECK-NEXT: d = {{0*}}6
-sim.func.dpi @mul_shared(in %a : i32, in %b : i32, out c : i32)
-sim.func.dpi @add_mlir(in %a : i32, in %b : i32, out c : i32) attributes {verilogName = "add_mlir_impl"}
+sim.func.dpi @mul_shared(input %a : i32, input %b : i32, output c : i32)


nit: Could you use in/out terminology for the consistency with module?

I could. I chose input/output etc for the same terminology as SystemVerilog. If considering this you are still sure you want to change it I will.

I generally prefer consistency with HW dialect over System verilog itself. SystemVerilog uses terminology input/output for ports, but we are using in/out for hw.module.

include/circt/Dialect/Sim/SimTypes.td

uenoku · 2026-03-30T18:28:37Z

include/circt/Dialect/Sim/SimTypes.h

+  KeyTy getAsKey() const { return ports; }
+
+  llvm::ArrayRef<DPIPort> getPorts() const { return ports; }
+


Could you consider store mlir::FunctionType in the storage?

DPIPort contains information about the direction and semantics of the arguments/ports. If we simply use FunctionType as storage we will not have this information which is integral to this change. Or maybe I misunderstood your meaning?

Ah I meant to simply store mlir::FunctionType in DPIFunctionTypeStorage, instead of storing in DPIFuncOp since it a bit weird that DPIFuncOp takes two types

include/circt/Dialect/Sim/SimTypes.td

…version function

uenoku · 2026-03-31T20:53:37Z

lib/Dialect/Sim/Transforms/LowerDPIFunc.cpp

+    auto it = state.dpiFuncDeclMapping.find(op.getCalleeAttr().getAttr());
+    if (it != state.dpiFuncDeclMapping.end())
+      op.setCallee(it->second.getSymNameAttr());


What was the reason for this behavior change?

uenoku · 2026-03-31T20:55:52Z

integration_test/arcilator/JIT/dpi.mlir

-sim.func.dpi @add_mlir(in %a : i32, in %b : i32, out c : i32) attributes {verilogName = "add_mlir_impl"}
+sim.func.dpi @mul_shared(input %a : i32, input %b : i32, output c : i32)
+sim.func.dpi @add_mlir(input %a : i32, input %b : i32, output c : i32) attributes {verilogName = "add_mlir_impl"}
 func.func @add_mlir_impl(%arg0: i32, %arg1: i32, %arg2: !llvm.ptr) {


Not blocking, but does JIT work with inout already?

uenoku · 2026-03-31T20:56:57Z

lib/Dialect/Sim/SimTypes.cpp

+// DPIFunctionType parser/printer
+//===----------------------------------------------------------------------===//
+
+/// Parse: !sim.dpi_functy<input "a" : i32, output "b" : i32>


Please add ronud-trip test for dpi_functy

uenoku · 2026-03-31T20:57:35Z

test/Dialect/Sim/lower-dpi-errors.mlir

+
+hw.module @top() {
+  hw.output
+}


nit: please insert newline at the end of file

Suggested change

}

}

uenoku reviewed Mar 19, 2026

View reviewed changes

pscabot requested review from darthscsi and seldridge as code owners March 23, 2026 12:26

pscabot force-pushed the dev/pscabot/sim_dpi_call branch from 71e2b6e to c85d35e Compare March 23, 2026 12:40

pscabot force-pushed the dev/pscabot/sim_dpi_call branch from c85d35e to 269f033 Compare March 23, 2026 13:18

pscabot requested a review from uenoku March 23, 2026 13:33

uenoku reviewed Mar 30, 2026

View reviewed changes

pscabot added 3 commits March 31, 2026 12:22

Rename DPI types to use function and args instead of module and ports

14023a6

Refactor DPIFunctionType: replace getHWModuleType with standalone con…

226a3e9

…version function

Fix formatting

ee0f160

uenoku reviewed Mar 31, 2026

View reviewed changes

		KeyTy getAsKey() const { return ports; }

		llvm::ArrayRef<DPIPort> getPorts() const { return ports; }

Conversation

pscabot commented Mar 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

uenoku left a comment

Choose a reason for hiding this comment

Uh oh!

pscabot commented Mar 19, 2026

Uh oh!

uenoku commented Mar 19, 2026

Uh oh!

pscabot commented Mar 24, 2026

Uh oh!

pscabot commented Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

uenoku left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

pscabot commented Mar 19, 2026 •

edited

Loading

pscabot commented Mar 30, 2026 •

edited

Loading