在综合中应避免使用哪些SystemVerilog特性？

Question

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

总之：我喜欢紧凑且易于维护的代码，但如果它在后端引起问题，就不好了。我应该避免什么？

编辑：针对关闭投票，我想尝试让问题更具体一些。这个问题是受到这个答案的启发而提出的。我很喜欢使用Dave所说的“糖”来降低代码复杂度，但如果某些综合工具会搞乱信号名称并使结果难以处理，那么我就不喜欢了。我正在寻找更多类似的例子。

- nguthrie

Answer 1

Theoretically, if you can write software that is synthesized into machine code to run on a piece of hardware, that software can be synthesized into hardware. And conversely, there are hardware constructs in Verilog-1995 that are not considered synthesizable simply because none of the major vendors ever got around to supporting it (e.g. assign/deassign). We still have people using //synopsis translate on/off because it took so long for them to support `ifdef SYNOPSYS.

大多数我认为在SystemVerilog中可安全综合的内容都是我称之为Verilog语法糖的东西。这只是用更少的打字方式编写相同Verilog代码的更方便的方法。例如：

- 数据类型：typedef、struct、enum、int、byte - 将这些类型用作端口、参数和函数返回值 - 赋值运算符：++ -- += - 类型转换和位流 - 包 - 接口 - 端口连接快捷方式 - 函数/任务/宏参数和端口连接的默认值

大多数属于这一类的构造都来自C语言，并不会真正改变代码的合成方式。只是更方便地定义和引用信号。

在动态分配存储的地方，合成就变得困难了。这将包括类对象、队列、动态数组和字符串，以及使用fork/join动态创建的进程。

我认为有些人对SystemVerilog存在误解，认为它只用于验证，而事实上标准的第一个版本是可合成子集，Intel是最早将其作为设计语言使用的用户之一。

- dave_59

---

如果在时钟块内使用 ++、-- 或 +=，可能会导致竞争条件。例如，请参见 https://sutherland-hdl.com/papers/2013-SNUG-SV_Synthesizable-SystemVerilog_paper.pdf。 - Hugh Perkins

@HughPerkins 如果变量正在被使用相同时钟的另一个进程读取，则可能会发生竞争。但这是模拟与综合陷阱的另一个问题。 - dave_59

Answer 2

SystemVerilog（SV）既可以用作硬件描述语言（HDL），也可以用作硬件验证语言（HVL），因此通常被称为“HDVL”。

SV中有几个有趣的设计结构可合成，可以代替旧的Verilog结构，有助于优化代码并实现更快的结果。

1. 在建模有限状态机时，SV的enum与Verilog的parameter相比。
2. 使用logic而不是reg和wire。
3. 使用always_ff、always_comb、always_latch代替Verilog中单个的always块。
4. 使用unique和priority语句代替Verilog的full和parallel case语句。
5. SV中提供了广泛的数据类型。

现在我所讨论的是SystemVerilog中用于RTL设计的这些结构。

但是，在验证环境中使用的结构是不可综合的。它们如下：

1. 动态数组和关联数组。
2. 程序块和时钟块。
3. 邮箱
4. 信号量
5. 类及其所有相关功能。
6. 任务
7. Chandle数据类型。
8. 队列。
9. 约束随机特性。
10. 延迟、等待和事件控制语句。

- Sougata