Support for system verilog interfaces in BlackBox modules

[cpehle]

Currently as far as I can tell there is no good way of wrapping a system verilog module with the "BlackBox" mechanism. While it is in principle possible to write adapter modules that have plain verilog ports on one side and system verilog interfaces on the other, it would be desirable to be able to wrap system verilog modules directly.

• Type of issue

  • [ ] Bug report
  • [x] Feature request
  • [ ] Other enhancement

• What is the use case for changing the behavior?

Easier integration of chisel modules in existing system verilog code bases.

• Impact

  • [x] API addition (no impact on existing code)

• Development Phase

  • [x] request
  • [ ] proposal

[azidar]

That would be great! Unfortunately, none of the developers are working on this at the moment, so its going to be a low priority item. We would happily review any code you would like to contribute, if you'd like to help out!

[zhutmost]

For example, I have a SystemVerilog module like this:

module Test #(parameter W = 16)(
    input  wire [1:0][W-1:0] a,
    ...
);
...

The input port a in this module is a unpacked array. The BlackBox cannot generate a correct Verilog port to connect it.

[NikolaosGian]

any update?

[seldridge]

The direction we've been pushing for this is to add port lowering ABIs to FIRRTL. See ABI v1 (aggregate types flattened to scalar types) and ABI v2 (aggregates preserved): https://github.com/chipsalliance/firrtl-spec/blob/main/abi.md#port-lowering-abis

ABI v2, I think, is exactly what @zhutmost is asking for. There may be issues here if the request becomes support for unpacked arrays or a mixture of packed and unpacked.

For interfaces, this is getting at a hypothetical ABI v3 or perhaps more fine-grained over the lowering of specific bundles where the ABI of a given port or type is clearly specified.