这是对 Morten 的第一个实体声明的修改，其中对于实例化 alu_div 的“模块”，我希望有一个组件声明，它提供名称 alu_div 的声明。
没有修饰该声明的属性，因此在标签 alu_div_0 处找到的实例没有属性 DELAY。
如果您要使用直接实体实例化，它可能会起作用：
entity alu_div is
constant MIN_DELAY : NATURAL := 42;
attribute DELAY : NATURAL;
attribute DELAY of alu_div : entity is MIN_DELAY;
end entity;
architecture foo of alu_div is
begin
end architecture;
entity test is
end entity;
architecture foo of test is
begin
alu_div_0:
entity work.alu_div ;
MONITOR:
process
begin
wait for 1 ns;
report "alu_div'DELAY = " & natural'image(work.alu_div'DELAY);
wait;
end process;
end architecture;
这给出了：
ghdl -a alu_div.vhdl
ghdl -e 测试
ghdl -r 测试
alu_div.vhdl:25:9:@1ns:(报告说明): alu_div'DELAY = 42
>
这个想法是，如果您使用具有选定名称（扩展名称）的直接实体实例化，则您使用的是由前缀指出的库中的声明（在本例中为 WORK）。
以下演示了访问alu_div'DELAY的值可以在阐述中完成：
entity alu_div is
generic (pickone: natural := 1);
constant MIN_DELAY : NATURAL := 42;
constant TARG_DELAY: natural := MIN_DELAY + pickone;
attribute DELAY : NATURAL;
attribute DELAY of alu_div: entity is MIN_DELAY;
-- attribute DELAY of alu_div : entity is TARG_DELAY;
end entity;
architecture foo of alu_div is
begin
end architecture;
entity test is
end entity;
architecture fie of test is
constant fumble: natural := work.alu_div'DELAY;
component alu_div is
generic (pickone: natural := 1);
end component;
begin
alu_div_0:
alu_div
generic map(1);
MONITOR:
process
begin
report "constant fumble = " & natural'image(fumble);
report "alu_div'DELAY = " & natural'image(work.alu_div'DELAY);
wait;
end process;
end architecture;
这很有效：
ghdl -a alu_div.vhdl
david_koontz@Macbook: ghdl -e test
david_koontz@Macbook: ghdl -r 测试
alu_div.vhdl:60:9:@0ms:(报告说明): 不断摸索 = 42
alu_div.vhdl:61:9:@0ms:(报告说明): alu_div'DELAY = 42
在 Jonathan 的评论之后，该问题试图通过泛型提供的实例化组件循环信息，我尝试将实体属性切换为依赖泛型（用MIN_DELAY 注释掉一个，用TARG_DELAY 取消注释) 并导致与 Morten 提供的错误不同：
ghdl -a alu_div.vhdl
alu_div.vhdl:36:13: 实体的属性表达式必须是本地静态
ghdl：编译错误
而且该错误在 2008 LRM 中非常有用且很容易找到，并且非常具体：
7.2 属性说明（第 8 段）：
表达式为继承该属性的每个命名实体指定该属性的值，作为该属性规范的结果。属性规范中表达式的类型应与相应属性声明中的类型标记相同（或隐式转换为）。 如果实体名称列表表示实体声明、架构主体、配置声明或声明为设计单元的未实例化包，则表达式必须是本地静态的（见 9.4.1）。 ...
此要求是在 '93 LRM（5.1 属性规范）中引入的。经过研究，我们发现在 -1992 年的标准化工作（在 -1993 年获得批准）中提出了out-mode generics。
同样在 '87 问题报告 40 (IR00040.txt) 中，在第一份 ISAC 基本原理报告中讨论了与从架构内设置属性相关的问题：
- 这样的能力会极大地（和负面地）影响至少一些
实施。一种直接的实施方法
规范是用信息来装饰命名实体
包含在规范中。 但是，当实体出现在
一个设计单元和适用的规范出现在另一个，
结果很多问题。没有就无法分析规范
修改包含实体的库单元，这可能导致
潜在的循环依赖链。 此外，多个
对应于给定实体接口的体系结构不能每个
为某些接口驻留的属性提供不同的值
实体。最后，没有 LRM 要求，如果一个架构
属性一些接口常驻实体，那么所有必须，这似乎
可取的。
您可能会注意到，对于依赖于泛型的属性，也可能出现不希望的循环依赖。或者类似地，对于外模式泛型，问题从分析顺序中的循环依赖（属性声明中的本地静态表达式）转移到可能相当困难的细化顺序（评估全局静态表达式）。 out-mode generics 在可用记录中显示零星提及，最后一次是在 vhdl-200x-mp（建模和生产力）电子邮件反射器上。
如果没有人定义如何处理后期绑定（链接加载器时间）顺序依赖关系，这两者的状态都不太可能发生变化。
与此同时，正如 Brian 所说，可接受的方法是使用一个通常共享的包，它使用本地静态常量声明（并且依赖于声明顺序）。您还可以通过配置来解决问题。