[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-30T18:28:37Z

+  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

…version function

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

+    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?

My bad. There is no "real" need for this change, and it is actually a bad change as it is implemented now. I wanted to avoid an undefined behavior in case of malformed IR (which should actually be caught before) but ended up silently masking the error. I will emit an explicit failure

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

-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?

As far as I can tell ARC goes through LowerDPIFunc so it should be supported. Should we add a test for it here? If it doesn't work, whould it be fixed as part of this PR?

No I was just curios! Thank you for checking!

uenoku

LGTM, thanks!

…i.call (llvm#9977) 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

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

Comment thread lib/Dialect/Sim/SimTypes.cpp

uenoku reviewed Mar 31, 2026

View reviewed changes

Comment thread test/Dialect/Sim/lower-dpi-errors.mlir Outdated

pscabot added 3 commits April 2, 2026 14:28

Cache FunctionType inside DPIFunctionTypeStorage

b405956

Change argument keywords to in/out

aa7790b

Add round-trip test for dpi_functy

760bb4b

uenoku approved these changes Apr 3, 2026

View reviewed changes

uenoku merged commit 1696571 into llvm:main Apr 3, 2026
7 of 8 checks passed

pscabot mentioned this pull request Apr 5, 2026

[Moore][ImportVerilog][MooreToCore] Add DPI call semantics to Moore #10126

Merged

		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!

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!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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

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!

Uh oh!

uenoku left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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

pscabot Apr 2, 2026 •

edited

Loading

uenoku left a comment •

edited

Loading