verilog - 在综合中应该避免哪些 SystemVerilog 特性？

Question

SystemVerilog 引入了一些非常有用的结构来改进编码风格。然而，正如我的一位同事经常说的，“你不是在写软件，你是在描述硬件。”考虑到这一点，当最终结果需要合成时，应该避免语言的哪些特征？这个paper显示了 Synopsys 工具当前可以合成哪些功能，但为了安全起见，我认为应该只使用所有主要供应商都可以合成的功能。此外，哪些结构会在网表中产生奇怪的结果，而这在 ECO 中很难遵循？

总结:我喜欢紧凑且易于维护的代码，但如果它会导致后端出现问题，我就不喜欢。我应该避免什么？

编辑:作为对接近投票的回应，我想尝试使这一点更加具体。这个问题的灵感来自 this回答。我非常喜欢使用 Dave 所说的“糖”来降低代码复杂性，但如果某些合成工具会破坏信号名称并使结果难以处理，我就不会这样做。我正在寻找更多这样的例子。

Answer 1

从理论上讲，如果您可以编写合成为机器代码以在硬件上运行的软件，则该软件可以合成为硬件。相反，Verilog-1995 中的一些硬件结构不被认为是可综合的，因为主要供应商都没有支持它(例如 assign/deassign )。我们仍然有人使用 //synopsis translate on/off因为他们花了很长时间才支持`ifdef SYNOPSYS .

大多数我认为是保险箱 SystemVerilog 中的综合是我所说的 Verilog 的语法糖。这只是用更少的输入编写相同的 Verilog 代码的更方便的方法。例子是:

数据类型:typedef、struct、enum、int、byte

将这些类型用作端口、参数和函数返回值

赋值运算符:++ -- +=

类型转换和比特流

包

接口(interface)

端口连接快捷方式

函数/任务/宏参数和端口连接的默认值

大多数属于这一类的结构都取自 C，并没有真正改变代码的合成方式。定义和引用信号更方便。

难以合成的地方是动态分配存储的地方。这将是类对象、队列、动态数组和字符串。以及使用 fork/join 动态创建的进程。

我认为有些人对 SystemVerilog 存在误解，认为它仅用于验证，而实际上该标准的第一个版本是可综合的子集， Intel是它作为设计语言的第一批用户之一。