llvm/circt

When using setInline on an ExtModule (blackbox annotations) in Chisel, firtool emits an incorrect warning that the circt.VerbatimBlackBoxAnno annotation remains unprocessed after LowerToHW. Run the following reproduction using scala-cli: //> using repository https://central.sonatype.com/repository/maven-snapshots //> using scala 2.13.18 //> using dep org.chipsalliance::chisel:7.16.0 //> using plugin org.chipsalliance:::chisel-plugin:7.16.0 //> using options -unchecked -deprecation -language:reflectiveCalls -feature -Xcheckinit //> using options -Xfatal-warnings -Ywarn-dead-code -Ywarn-unused -Ymacro-annotations import chisel3._ // _root_ disambiguates from package chisel3.util.circt if user imports chisel3.util._ import _root_.circt.stage.ChiselStage class InlinePassThrough extends ExtModule { val in = IO(Input(UInt(8.W))) val out = IO(Output(UInt(8.W))) setInline( "InlinePassThrough.v", """module InlinePassThrough(input [7:0] in, output [7:0] out); | assign out

Streaming concatenation operators ({>>{...}}, {<<{...}}) need to convert non-packed, fixed-size aggregates (unpacked arrays, unpacked structs) to and from a flat packed bit vector, and ImportVerilog has no such conversion, so any streaming operand that isn't already a plain packed type fails to import. This bug used to be hidden by the moore.conversion op that pretended to convert an unpacked array to a dense bit vector. That op no longer exists after #11024. module Streaming; logic [15:0] vec_3; logic [31:0] vec_1; logic arr_1 [63:0]; initial begin vec_1 = {<<byte{vec_3, arr_1 with [15:0]}}; {<<byte{vec_3, arr_1 with [15:0]}} = vec_1; end endmodule error: unsupported conversion from '!moore.uarray<16 x l1>' to '!moore.l16' Per IEEE 1800-2017 §11.4.14, streaming braces accept packed types, strings, unpacked arrays (fixed-size, dynamic, and queues), unpacked structs/unions, and class handles (source-only); with [..] part-select is further restricted to fixed-size un

Removing the moore.conversion op in #11024 has revealed two related gaps in converting between fixed-size and dynamically-sized array types: a fixed-size unpacked array (e.g. an array literal) assigned to a dynamic array has no conversion path, and a plain packed bit vector passed as the actual argument to a DPI import whose formal parameter is a packed open array has no conversion path either. string strArr[] = { "hello", "sad", "world" }; error: unsupported conversion from '!moore.uarray<3 x string>' to '!moore.open_uarray<string>' import "DPI-C" function void packed_bits_fn(input bit [] data); bit [7:0] pdata; packed_bits_fn(pdata); error: unsupported conversion from '!moore.i8' to '!moore.open_array<i1>' For the first case, there's no op to build an open unpacked array from element values or from a fixed-size array value — OpenUArrayCreateOp only allocates an array of a given size (new[N]). Queues have an analogous, working conversion (QueueFromUnpackedArrayOp) that a dynamic-a

#11024 removed support for casting a fixed-size array to a DPI open-array parameter of matching element type, e.g. binding a byte data[8] actual to a byte data[] parameter in a DPI function. Test coverage for this was dropped from test/Conversion/MooreToCore/dpi-open-array.mlir test/Conversion/MooreToCore/moore-dpi-call-lowering.mlir test/Conversion/MooreToCore/errors.mlir This was originally added by @pscabot in #9882. With the moore.conversion op gone, we'll need a dedicated conversion op to support this case again.

There are several Synth passes that are restricted to hw.module but there is no good reason to keep it specific to hw.module.