Direction 'InOut' on inlined port connection unsupported

[B3rndK]

Hello, sorry for bothering but I just changed over from plain verilog (yosys) to system verilog using the yosys_slang module. After I fixed several warnings thankfully shown by slang, I am now left with 8x the same error which is, as I thing, doing some really easy stuff:

I am instantiating a module from my top-level module. It is using eight inout wires "io_psram_data0"-"io_psram_data7" which I named all the same in the .ccf file, in my instantiation and in the module itself:

[TOPLEVEL]
(...)
memCtrl U13_U25(
.i_clkRAM(clkSys),
.reset(rst),
(...)
.io_psram_data0(io_psram_data0),
.io_psram_data1(io_psram_data1),
.io_psram_data2(io_psram_data2),
.io_psram_data3(io_psram_data3),
.io_psram_data4(io_psram_data4),
.io_psram_data5(io_psram_data5),
.io_psram_data6(io_psram_data6),
.io_psram_data7(io_psram_data7),
(...)

[MODULE]
(...)
module memCtrl( input logic i_clkRAM, // RAM clock (100Mhz)
input logic reset,
(...)
inout wire io_psram_data0,
inout wire io_psram_data1,
inout wire io_psram_data2,
inout wire io_psram_data3,
inout wire io_psram_data4,
inout wire io_psram_data5,
inout wire io_psram_data6,
inout wire io_psram_data7,
(...)

OUTPUT:

1. Executing SLANG frontend.
   Top level design units:
   gm64

in file included from src/gm64.v:14:
memCtrl/src/memCtrl.v:21:28: error: direction 'InOut' on inlined port connection unsupported
inout wire io_psram_data0,
^
memCtrl/src/memCtrl.v:22:28: error: direction 'InOut' on inlined port connection unsupported
inout wire io_psram_data1,
^
memCtrl/src/memCtrl.v:23:28: error: direction 'InOut' on inlined port connection unsupported
inout wire io_psram_data2,
^
memCtrl/src/memCtrl.v:24:28: error: direction 'InOut' on inlined port connection unsupported
inout wire io_psram_data3,
^
memCtrl/src/memCtrl.v:25:28: error: direction 'InOut' on inlined port connection unsupported
inout wire io_psram_data4,
^
memCtrl/src/memCtrl.v:26:28: error: direction 'InOut' on inlined port connection unsupported
inout wire io_psram_data5,
^
memCtrl/src/memCtrl.v:27:28: error: direction 'InOut' on inlined port connection unsupported
inout wire io_psram_data6,
^
memCtrl/src/memCtrl.v:28:28: error: direction 'InOut' on inlined port connection unsupported
inout wire io_psram_data7,
^

Build failed: 8 errors, 0 warnings

Sorry for this question, I digged a lot and studied several system verilog articles but I cannot find out why this should not work...??.

Any help is greatly appreciated.

Thanks,
Bernd.

[povik]

Hi @B3rndK, I'm happy to help. This is a limitation of yosys-slang. As a workaround you can try enabling --keep-hierarchy. In this mode the design is loaded into Yosys with preserved module boundaries, the ports are not inlined and as such they can have the inout direction.

[NickSica]

Does the keep-hierarchy flag cause slang to keep all the duplicates of parameterized modules? If so, is there an alternative to this? If not, is there a way to collapse parameterized modules that end up being the same instead of having a bunch of copies of the same module?

[povik]

Does the keep-hierarchy flag cause slang to keep all the duplicates of parameterized modules?

Yes, one per instantiation anywhere in the design hierarchy. Support for re-using the same module definition for cases where an equivalent module is instanced multiple times is tracked under #4

If so, is there an alternative to this?

Not at the moment. Either you have --keep-hierarchy and module copy per each instance, or you don't have --keep-hierarchy in which case all of the design is flattened into a top module.

[NickSica]

Does the keep-hierarchy flag cause slang to keep all the duplicates of parameterized modules?

Yes, one per instantiation anywhere in the design hierarchy. Support for re-using the same module definition for cases where an equivalent module is instanced multiple times is tracked under #4

If so, is there an alternative to this?

Not at the moment. Either you have --keep-hierarchy and module copy per each instance, or you don't have --keep-hierarchy in which case all of the design is flattened into a top module.

Ok so this isn't an issue attached to --keep-hierarchy. I think #4 is what I need specifically. Thank you.

[povik]

Yes, the slang support for this has moved forward (MikePopoloski/slang#949 is now closed) but yosys-slang doesn't make use of this yet