在综合中应避免使用SystemVerilog的功能？

Question

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

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

编辑：为了回应投票，我想尝试使其更加具体。这个问题的灵感来自this。我很喜欢使用'糖'，因为Dave称之为降低代码复杂性，但是如果某些综合工具会破坏信号名称并使结果难以处理，那就不行了。我正在寻找更多这样的例子。

Answer 1

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

我认为SystemVerilog中用于合成的大部分安全是我称之为Verilog的 syntactic sugar 。这是编写相同Verilog代码的更方便的方法，而且打字少得多。例如：

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

属于此类别的大多数构造都取自C，并没有真正改变代码的合成方式。定义和参考信号更方便。

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

我认为有些人对SystemVerilog有一种误解，认为它只适用于Verification，而实际上标准的第一个版本是可综合的子集，而Intel是其作为语言的第一批用户之一设计。

Answer 2

SystemVerilog（SV）既可以用作HDL（硬件描述语言），也可以用作HVL（硬件验证语言），这就是它通常被称为HDVL的原因。

SV中有很多有趣的设计构造，它们是可综合的，可以代替Verilog构造代替Verilog构造，这有助于优化代码并实现更快的结果。

1. 在建模FSM时SV的枚举与verilog的参数。
2. 使用Logic代替reg和wire。
3. 使用always_ff，always_comb，always_latch取代  单一的总是Verilog块。 4.使用唯一和优先级声明而不是Verilog 完整而平行的案例。
4. SV中提供的各种数据类型。

现在我上面讨论过的是那些在RTL设计中使用的SystemVerilog构造

但是在验证环境中使用的构造是不可合成的。它们如下： -

1.动态数组和关联数组。 2.程序块和时钟块。 3.Mailbox 4.Semaphore 5.课程及其所有相关功能。 6.Tasks 7.Chandle数据类型。 8.Queues。 9.约束随机特征。 10.延迟，等待和事件控制声明。