SystemVerilog 引入了一些非常有用的结构来改进编码风格。然而，正如我的一位同事经常说的，“你不是在写软件，你是在描述硬件。”考虑到这一点，当最终结果需要合成时，应该避免语言的哪些特征？这个paper 显示了 Synopsys 工具当前可以综合哪些功能，但为了安全起见，我认为应该只使用所有主要供应商都可以综合的功能。此外，哪些结构会在网表中产生奇怪的结果，而在 ECO 中很难遵循？
总而言之：我喜欢紧凑且易于维护的代码，但如果它会导致后端出现问题，则不喜欢。我应该避免什么？
编辑：作为对票数接近的回应，我想尝试更具体一点。这个问题的灵感来自this 答案。我非常喜欢使用 Dave 所说的“糖”来降低代码复杂性，但如果某些合成工具会破坏信号名称并使结果难以处理，我就不会这样做。我正在寻找更多这样的例子。
【问题讨论】：
理论上，如果您可以编写合成为机器代码的软件以在硬件上运行，则该软件可以合成为硬件。相反，Verilog-1995 中的一些硬件结构不被认为是可综合的，因为主要供应商都没有支持它（例如assign/deassign）。我们仍然有人使用//synopsis translate on/off，因为他们花了很长时间才支持`ifdef SYNOPSYS。
我认为在 SystemVerilog 中合成安全的大部分是我称之为 Verilog 的语法糖。这只是用更少的输入编写相同的 Verilog 代码的更方便的方法。例如：
大多数属于这一类的结构都取自 C，并没有真正改变代码的合成方式。定义和引用信号更方便。
难以综合的地方是动态分配存储的地方。这将是类对象、队列、动态数组和字符串。以及使用 fork/join 动态创建的进程。
我认为有些人对 SystemVerilog 存在误解，认为它仅用于验证，而事实上该标准的第一个版本是可综合的子集，而 Intel 是它作为设计语言的第一批用户之一。
【讨论】：
++, --, += 如果在时钟块内使用会导致竞争条件，例如见sutherland-hdl.com/papers/…
SystemVerilog(SV) 可以用作 HDL（硬件描述语言）和 HVL（硬件验证语言），这就是为什么它通常被称为“HDVL”。
SV 中有几个有趣的设计结构，它们是可综合的，可以用来代替旧的 Verilog 结构，它们有助于优化代码并获得更快的结果。
enum 与 Verilog 的 parameter 在 FSM 建模时。logic 代替reg 和wire。always_ff、always_comb、always_latch 代替
Verilog 中的单个 always 块。unique 和priority 语句代替Verilog 语句
full 和 parallel 案例陈述。现在我上面讨论的是那些用于 RTL 设计的 SystemVerilog 结构。
但是，验证环境中使用的构造是不可综合的。它们如下：
【讨论】：