似乎世界已经决定std_logic
(and std_logic_vector
) 是 VHDL 中表示位的默认方式。替代方案是std_ulogic
,但未解决。
这让我感到惊讶,因为通常,您不是在描述总线,所以您不想要多个驱动程序并且您不需要解析信号。这样做的好处std_ulogic
是,如果您有多个驱动程序,编译器会尽早警告您。
问题:这只是一个文化/历史的事情,还是还有使用 std_logic 的技术原因?
似乎世界已经决定std_logic
(and std_logic_vector
) 是 VHDL 中表示位的默认方式。替代方案是std_ulogic
,但未解决。
这让我感到惊讶,因为通常,您不是在描述总线,所以您不想要多个驱动程序并且您不需要解析信号。这样做的好处std_ulogic
是,如果您有多个驱动程序,编译器会尽早警告您。
问题:这只是一个文化/历史的事情,还是还有使用 std_logic 的技术原因?
Std_logic是 std_ulogic 的子类型,并且有一个额外的属性:如果有多个驱动程序,它就会被解析。
无论常见做法如何,std_ulogic 都是用于需要 9 值逻辑的未解析信号的正确类型。(通常,使用“位”更正确——例如,在一些没有“X”或“U”之类的 FPGA 架构上)。
基本上,最好的办法是为工作使用正确的类型。不良做法通常会被人们传播,只是模仿他们看到别人使用的风格,而不了解原因。
我的历史是这样的:
我开始(大约在 1999 年 IIRC)std_ulogic*
一直使用 - 因为这是正确的做法,正如你所描述的原因。
然后我必须连接到一堆向导生成的供应商 IP,这些 IPstd_logic
都在接口上。这意味着端口映射(对于_vector
元素)的转换,我变得懒惰并转向使用std_logic*
.
然而,我似乎很少犯“双重驱动”错误,所以我并没有std_ulogic
像我想象的那样错过太多。drivers
当我偶尔需要时,Modelsim 的命令可以很容易地找到“谁在驾驶什么”……
IIRC 推荐了著名的重用方法手册std_logic(_vector)
,因此公司中的方法论小组等可能以(强制性)编码指南的形式进一步传播。就个人而言,+1std_ulogic
尽可能使用。
我知道它是一个可怕的彩色 ppt 幻灯片,但它很好地解释了不同之处: