我发现从Chisel框架生成Verilog输出时，在Chisel框架中定义的所有“结构”都在接口处丢失了。
这对于在较大的SystemVerilog设计中实例化此工作是有问题的。
Chisel中是否有任何扩展或功能可以更好地支持此功能？例如，将凿子“捆绑”对象自动转换为SystemVerilog的“结构”端口。
使用Enum类编写Chisel代码时，或者创建SV枚举。
答案 0 :(得分：2)
当前，不可以。但是，这两个建议听起来都非常适合讨论如何在Chisel / FIRRTL中实现。
在Verilog / SystemVerilog中实例化的大多数Chisel代码将使用一些接口包装程序，该程序将实例化程序要使用的必要信号名称转换为Chisel友好名称。作为执行此操作的一个示例，请参见AcceleratorWrapper。实例化一个特定的加速器，并连接到实例化程序期望的Verilog名称。您目前无法使用SystemVerilog结构执行此操作，但是可以通过将SystemVerilog结构映射到确定性凿子名称的SystemVerilog包装器来完成同一操作。这是大多数人将外部IP集成到他们的项目中时遇到的相同类型的问题/解决方案。
撇开一切，未来您可能会谈论...
为什么这很复杂需要一些解释：
凿子转换为FIRRTL。然后，将FIRRTL降低为FIRRTL的精简子集，称为“低” FIRRTL。然后将低FIRRTL映射到Verilog。降低过程的一部分使用唯一确定的名称来平整所有包（通常a.b.c会降低到a_b_c，但是如果由于降低而导致名称空间冲突，则将被唯一化）。 Verilog不支持结构，因此必须做到这一点。此外，更关键的是，在低FIRRTL级别上进行了一些优化，如“恒定传播”和“消除死代码”，这些优化在此处更容易编写和处理。
但是，FIRRTL后端所针对的SystemVerilog或其他支持非固定类型的语言将受益于使用该语言的功能来产生更易于理解的输出。有两种一般方法可以纠正此问题：
降低的类型保留有关它们最初如何通过注释构造的信息，而SystemVerilog发射器将重构这些信息。由于降下然后再降下，因此效果似乎不太好。
SystemVerilog发射器使用不同的FIRRTL转换序列，这种转换并不会一直到Low FIRRTL。这将需要对在低FIRRTL上运行的一些优化转换进行重写，以在更高的格式上工作。这很容易处理，但是很难。
如果您想了解有关每个编译器阶段运行哪些遍的更多信息，请查看LoweringCompilers.scala
您为Enum提及的内容计划用于Verilog后端。这里的想法是让Enum发出描述它们是什么的注释。然后，Verilog发射器将生成localparam。注释生成的前期工作已作为StrongEnum（chisel3#885 / chisel3#892）的一部分添加，但注释部分必须稍后撤消。目前正在积极寻求解决方案。随后FIRRTL的PR将增强Verilog发射器以使用它们。因此，请期待这种情况。
对于带有（当前）否定答案的此类问题，请随时在各自的Chisel3或FIRRTL存储库中提出问题。甚至比这更好的是RFC及其后的实现。