我正在学习VHDL并发现令人困惑的事情 . 假设您有以下实体:
entity alu32 is
port(a, b : in STD_LOGIC_VECTOR(31 downto 0);
alucontrol : in STD_LOGIC_VECTOR(2 downto 0);
result : buffer STD_LOGIC_VECTOR(31 downto 0);
zero : out STD_LOGIC);
end alu32;
当将它用作另一个实体架构中的组件时,它的定义如下:
component alu32
port(
a, b : in STD_LOGIC_VECTOR(31 downto 0);
alucontrol : in STD_LOGIC_VECTOR(2 downto 0);
result : buffer STD_LOGIC_VECTOR(31 downto 0);
zero : out STD_LOGIC
);
end component;
我的问题是,为什么要重新定义港口?这似乎是一个毫无意义的练习,因为它与实体声明中的完全相同 . 为什么VHDL设计不允许您简单地使用这样的组件:
component alu32;
3 回答
你可以,因为VHDL-93 . 您可以实例化使用
在此片段中,您可以将
work
替换为要实例化的组件的VHDL库,work
始终是VHDL源所在的当前库 .为什么要使用组件声明?首先,如果要实例化的内容不是VHDL,则需要它们,例如Verilog,IP内核和网表 . 其次,使用配置允许更改端口/实体绑定,但您需要组件声明 .
本质上,语言设计师们正在尽可能仔细地向前看,这个世界并没有那样发生 .
component
声明的想法是它确切地定义了实例化时的预期,因此使用这些组件的实体/体系结构是自洽的,可以编译并在某种程度上作为独立任务从其使用的组件中进行测试 - 甚至可能在编写这些组件之前 .Bill Lynch的评论与此相关,今天很容易忘记:编译时间长了一千倍,这是一个很大的 生产环境 力胜利
稍后,当您构建整体设计时,将在组件库中搜索该组件,并找到完全匹配的实体(默认配置),或者通过
configuration
语句选择特定组件 . 或者细化失败,将不匹配报告为错误 - 没有机会创建一个不太合适的部分的设计 . 该库可以包含各种具有不同特性的"alu32"组件,用于不同目的(快速,小型,有/无浮点等) . 这发生在"elaboration",大致与软件中的链接阶段相同,当(希望)找到正确的实体/ arch,并且检查其端口与组件的端口时 . 对于那些以“The TTL Data Book”成长的设计师而言,这是一种自然的方式,可以看到设计的发展 - 这是一个TTL IC形式的物理构建模块库 .但是,在今天的典型用例中,我们不会在很大程度上使用组件库,因此您的示例中的“alu32”可能是同一项目中的另一个文件,编译到您的“工作”库中 .
在这种情况下,Jonathan Drolet回答的更简单,更简单的“直接实体实例化”(1993年引入)是正确的方法 . 下行?它确实意味着你必须编写 - 并成功编译 - “alu32”实体,然后才能进行语法检查顶级设计(尽管你可以在以后的详细说明中编写体系结构) .
IEEE Std 1076-2008,6.8组件声明
3.4配置声明
组件声明就像Function prototype . 通用映射或端口映射方面是绑定指示的一部分 .
附件一:
作为您要考虑与配置声明一起使用的组件声明的示例,内部块具有相同接口的设计:
它们实际上是不同的,你使用多个:
封闭实体在其他方面是相同的(dslice) .
您可以指定在详细说明期间使用的实体:
在这种情况下的DES加密算法可以被描述为由替换盒内容和外部互连区分的四个部分中的硬件 .
这个设计模型演示了数字加密标准(FIPS Pub 46,单DES)中的数字加密算法的硬件特性 . 你可以仔细看看这个链接 - vhdl_des.tar.gz .
对于不支持配置的综合或仿真工具,替代方案是统一包含实例化实体的块,在这种情况下,将设计描述的大小增加几乎四倍,同时增加维护和不必要复制的危险 .