[ExportVerilog] Type scope emission in split outputs mode

[uenoku]

Currently type scopes are all copied to each output file:
For example this mlir, firtool -split-verilog creates two files "UseA.sv" and "UseB.sv".

hw.type_scope @scope_A  { hw.typedecl @T_A : i1 }
hw.module @UseA(%source: !hw.typealias<@scope_A::@T_A, i1>) {}
hw.type_scope @scope_B  { hw.typedecl @T_B : i1 }
hw.module @UseB(%source: !hw.typealias<@scope_B::@T_B, i1>) {}

Followings are current outputs.

• UseA.sv

typedef logic T_A;
module UseA(    // hoge.mlir:2:1
  input T_A source);

endmodule

typedef logic T_B;

• UseB.sv

typedef logic T_A;
typedef logic T_B;
module UseB(    // hoge.mlir:4:1
  input T_B source);

endmodule

It is better not to emit all type decls but emit subsets of types used by emitted module.

[mikeurbach]

This is a good question, and we had some prior discussion about this. This came up in the December 1 ODM, but I'm not sure we had any concrete issues filed about it.

IIRC the discussion was around generating a .svh header file containing the typedefs, with macros to make it safe to include at the top and bottom of any file. I don't recall if any thought has been given to splitting it up by which types are needed in each output file, but that could be interesting too.

@darthscsi or @teqdruid did you have any thoughts on this one?

[teqdruid]

I've been meaning to get the typedefs in one header file which gets included. Having duplicate typedefs (in different files) turns out to be a bad idea since some EDA tools essentially append all the files in a "translation unit" (command line invocation) together and then complain that the typedef is being multiply defined. So the syntactic correctness depends on the specific translation units, which is really up to the build system to figure out.

... all of which is a long-winded way of saying that header files are the right way to go. IIRC, that's the TL;DR of that meeting.

[uenoku]

Thanks, generating header files totally makes sense to me!

Having duplicate typedefs (in different files) turns out to be a bad idea since some EDA tools essentially append all the files in a "translation unit" (command line invocation) together and then complain that the typedef is being multiply defined. So the syntactic correctness depends on the specific translation units, which is really up to the build system to figure out.

Actually I encountered the error to complain about the multiple definitions. Maybe inserting include guards to type scopes is a good as workarounds?