使用 SystemVerilog 接口(interface)/结构的 Chisel 输出

Question

我发现当从 Chisel 框架生成 Verilog 输出时，Chisel 框架中定义的所有“结构”都在接口(interface)处丢失了。

这对于在更大的 SystemVerilog 设计中实例化这项工作是有问题的。

Chisel 中是否有任何扩展或功能可以更好地支持这一点？例如，自动将 Chisel“Bundle”对象转换为 SystemVerilog“结构”端口。

或者创建 SV 枚举，当使用 Enum 类编写 Chisel 代码时。

Answer 1

目前，没有。然而，这两个建议听起来都非常适合讨论 future 在 Chisel/FIRRTL 中的实现。

SystemVerilog 结构生成

大多数在 Verilog/SystemVerilog 中实例化的 Chisel 代码将使用一些接口(interface)包装器来处理将实例化器想要使用的必要信号名称转换为 Chisel 友好的名称。作为这样做的一个例子，请参见 AcceleratorWrapper .这会实例化一个特定的加速器并连接到实例化器期望的 Verilog 名称。您目前无法使用 SystemVerilog 结构执行此操作，但您可以使用将 SystemVerilog 结构映射到确定性 Chisel 名称的 SystemVerilog 包装器来完成相同的操作。这与大多数人在项目中集成外部 IP 时遇到/解决的问题/解决方案类型相同。

抛开 Kludges 不谈，你所说的在未来是可能的......

有必要解释一下为什么这很复杂:

凿子转换为 FIRRTL。然后将 FIRRTL 降低为 FIRRTL 的一个缩减子集，称为“低”FIRRTL。然后将低 FIRRTL 映射到 Verilog。此降低过程的一部分使用唯一确定的名称扁平化所有包(通常 a.b.c 将降低为 a_b_c 但如果由于降低而导致命名空间冲突，则将是唯一的)。 Verilog 不支持结构，所以这必须发生。此外，更重要的是，一些优化发生在低 FIRRTL 级别，例如更易于编写和处理的恒定传播和死代码消除。

但是，SystemVerilog 或 FIRRTL 后端所针对的支持非平面类型的某些其他语言受益于使用该语言的功能来生成更多人类可读的输出。有两种一般方法可以纠正此问题:

1. 低级类型保留有关它们最初是如何通过注释构造的信息，而 SystemVerilog 发射器会重建这些信息。由于降低然后又不降低，这似乎不雅。

2. SystemVerilog 发射器使用不同的 FIRRTL 变换序列，它不会一直到低 FIRRTL。这将需要重写一些在低 FIRRTL 上运行的优化转换以在更高的形式上运行。这很容易处理，但很难。

如果您想了解每个编译器阶段运行哪些遍的更多信息，请查看 LoweringCompilers.scala

枚举类型

你提到的 Enum 是为 Verilog 后端计划的。这里的想法是让 Enum 发出描述它们是什么的注释。然后，Verilog 发射器将生成 localparam。注释生成的初步工作是作为 StrongEnum ( chisel3#885/chisel3#892 ) 的一部分添加的，但注释部分后来不得不取消。正在积极研究对此的解决方案。随后对 FIRRTL 的 PR 将增加 Verilog 发射器以使用这些。所以，请期待这一点。

关于贡献和外展

对于此类(当前)答案是否定的问题，请随时在相应的 Chisel3 或 FIRRTL 存储库中提交问题。甚至比这更好的是一个 RFC，然后是一个实现。