chisel - 具有SystemVerilog接口(interface)/结构的凿子输出

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

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

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

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

最佳答案

目前没有。但是，这两个建议听起来都非常适合讨论如何在Chisel / FIRRTL中实现。

SystemVerilog结构生成

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

撇开一切， future 您可能会谈论...

为什么这很复杂需要一些解释:

凿子转换为FIRRTL。然后，将FIRRTL降低为FIRRTL的简化子集，称为“低” FIRRTL。然后将低FIRRTL映射到Verilog。降低过程的一部分使用唯一确定的名称来平整所有包(通常a.b.c将降低为a_b_c，但是如果由于降低而导致 namespace 冲突，则将被唯一化)。 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发射器以使用它们。因此，展望 future 。

贡献与外展

对于具有(当前)否定答案的此类问题，请随时在各自的Chisel3或FIRRTL存储库中提出问题。甚至比这更好的是RFC及其后的实现。

关于chisel - 具有SystemVerilog接口(interface)/结构的凿子输出，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/53198767/