我发现，当从Chisel框架生成Verilog输出时，在Chisel框架中定义的所有"结构"都会在接口处丢失。
这对于在更大的SystemVerilog设计中实例化这项工作是有问题的。
Chisel中是否有任何扩展或功能可以更好地支持这一点？例如，自动将Chisel"Bundle"对象转换为SystemVerilog"struct"端口。
或者在使用Enum类编写Chisel代码时创建SV枚举。
目前没有。然而，这两个建议听起来都是未来在Chisel/FIRRTL中实施的很好的讨论对象。
SystemVerilog结构生成
Verilog/SystemVerilog中实例化的大多数Chisel代码都会使用一些接口包装器，用于将实例化器想要使用的必要信号名称转换为Chisel友好名称。作为这样做的一个示例，请参见AcceleratorWrapper。它实例化一个特定的加速器，并连接到实例化器所期望的Verilog名称。您目前无法使用SystemVerilog结构来实现这一点，但您可以使用SystemVerilog包装器来实现同样的事情，该包装器将SystemVerilog结构化映射到确定性Chisel名称。这与大多数人在项目中集成外部IP时遇到/解决的问题/解决方案类型相同。
撇开Kludges不谈，你所说的在未来是可能的。。。
有必要对为什么这很复杂进行一些解释：
凿被转换为FIRRTL。然后将FIRRTL降低为FIRRTL的一个简化子集，称为"低"FIRRTL。然后将低FIRRTL映射到Verilog。这个降低过程的一部分使用唯一确定的名称来平坦化所有捆绑包(通常a.b.c将降低到a_b_c，但如果由于降低而导致命名空间冲突，则将被统一(。Verilog不支持structs，所以这是必须的。此外，更重要的是，一些优化发生在Low-FIRRTL级别，如Constant Propagation和Dead Code Elimination，在那里更容易编写和处理。
然而，SystemVerilog或FIRRTL后端所针对的支持非平面类型的其他语言可以从使用该语言的功能来产生更易于阅读的输出中获益。纠正这种情况有两种通用方法：
-
降低的类型保留了关于它们最初是如何通过注释构建的信息，SystemVerilog发射器会重建这些信息。这似乎是不雅的，因为降低，然后不降低。
-
SystemVerilog发射器使用不同的FIRRTL转换序列，该序列不会一直到低FIRRTL。这将需要重写在Low-FIRRTL上运行的一些优化转换，以便在更高的形式上工作。这很容易处理，但很难。
如果您想了解有关在每个编译器阶段运行哪些传递的更多信息，请查看LoweringCompilers.scala
枚举的类型
您提到的Enum计划用于Verilog后端。这里的想法是让Enum发出描述它们是什么的注释。Verilog发射器随后将生成localparams。注释生成的初步工作作为StrongEnum(chisel3#885/chisel3#892(的一部分添加，但注释部分后来必须退出。目前正在积极研究解决方案。FIRRTL的后续PR将增强Verilog发射器以使用这些发射器。所以，期待这一进展。
论贡献与拓展
对于(目前(答案为否定的此类问题，请随时在各自的Chisel3或FIRRTL存储库中提交问题。比这更好的是一个RFC，然后是一个实现。