综合中应避免哪些 SystemVerilog 特性? [英] What SystemVerilog features should be avoided in synthesis?

问题描述

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

SystemVerilog introduced some very useful constructs to improve coding style. However, as one of my coworkers always says, "You are not writing software, you are describing hardware." With that in mind, what features of the language should be avoided when the end result needs to be synthesized? This paper shows what features are currently synthesizable by the Synopsys tools, but to be safe I think one should only use the features that are synthesizable by all of the major vendors. Also, what constructs will produce strange results in the netlist which will be difficult to follow in an ECO?

总而言之:我喜欢紧凑且易于维护的代码，但如果它会导致后端出现问题，则不喜欢.我应该避免什么?

In summary: I like compact and easy to maintain code, but not if it causes issues in the back end. What should I avoid?

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

In response to the close vote I want to try to make this a bit more specific. This question was inspired by this answer. I am a big fan of using the 'sugar' as Dave calls it to reduce the code complexity, but not if some synthesis tools are going to mangle signal names and make the result difficult to deal with. I am looking for more examples like this.

推荐答案

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

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 代码更方便的方法.例如:

Most of what I consider to be safe for synthesis in SystemVerilog is what I call syntactic sugar for Verilog. This is just more convenient ways of writing the same Verilog code with a lot less typing. Examples would be:

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

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

Most of the constructs that fall into this category are taken from C and don't really change how the code gets synthesized. It's just more convenient to define and reference signals.

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

The place it gets difficult to synthesize is where there is dynamically allocated storage. This would be class objects, queues, dynamic arrays, and strings. as well as dynamically created processes with fork/join.

我认为有些人对 SystemVerilog 有误解，认为它仅用于验证，而实际上标准的第一个版本是可合成的子集，并且 英特尔 是其作为设计语言的首批用户之一.

I think some people have a misconception about SystemVerilog thinking it is only for Verification when in fact the first version of the standard was the synthesizable subset, and Intel was one of the first users of it as a language for Design.

这篇关于综合中应避免哪些 SystemVerilog 特性?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！