External name elaboration order

[valtih1978]

In "Designer's guide to VHDL", Chapter 18, I read:

- BEGIN QUOTE -
"We can use an external constant name (or an alias of such a name) in an
expression, provided the constant has been elaborated and given a value
by the time the expression is evaluated. In some cases, expressions are
evaluated during elaboration of a design."

"We can ensure this is the case by writing the part of the design that
includes the constant declaration prior to the part of the design that
contains the external constant name. VHDL’s elaboration rules specify
that the design is elaborated in depth-first top-to-bottom order."

"We now assemble the design and test bench in a top-level entity and
architecture:

architecture level of top is
begin
assert false report "Width = " & to_string(<<constant .top.duv.width
: natural>>);
duv : entity work.design(rtl);

"The external constant name in the concurrent assertion statement, on
the other hand, is not evaluated until the model is executed, by which
time the model is completely elaborated. Thus, the external constant
name is allowed to precede the instance of the design under test in
which the constant is declared.

- END QUOTE -

It says that to be sure that referenced constant is evaluated prior to
external name reference is evaluated, "declare the constant prior to the
part of the design that contains the external constant name". But, in
example we see the opposite: constant is declared in the instance below
the assertion elaboration!

Then, it reassures us that this is ok and develops this idea by denying it!

"VHDL has a related rule regarding elaboration of a signal referenced by
an external signal name. If such a name (or an alias of such a name) is
used in a port map, the signal declaration must have been previously
elaborated. The reason is that the hierarchy of signal nets and drivers
is built during elaboration. If a signal used in a port map is not yet
elaborated, the elaborator would have to revisit elaboration of that
part of the design hierarchy once the signal declaration was
encountered. In general, allowing such use of external signal names
would make elaboration of signal nets indefinitely complicated. The rule
preventing such use allows elaboration to proceed in a well-defined
order, and is not onerous in practice."

That is, they say that situation is the same and object, referenced in
external name, must be elaborated before external name.


alias DONE_SIG is <<signal DUT.DONE: BIT>>; -- Legal
begin
DUT: entity WORK.MY_DESIGN port map (s1, S2, S3);

We do not want to re-elaborate the alias, once the signal declaration
was encountered during instance elaboration. Right?

After all, I could not understand if your VHDL example is correct or not.

[Alan Fitch]

On 28/11/11 11:32, valtih1978 wrote:
> In "Designer's guide to VHDL", Chapter 18, I read:
>
> - BEGIN QUOTE -
> "We can use an external constant name (or an alias of such a name) in an
> expression, provided the constant has been elaborated and given a value
> by the time the expression is evaluated. In some cases, expressions are
> evaluated during elaboration of a design."
>
> "We can ensure this is the case by writing the part of the design that
> includes the constant declaration prior to the part of the design that
> contains the external constant name. VHDL’s elaboration rules specify
> that the design is elaborated in depth-first top-to-bottom order."
>

Hi,
I understand that to say in the first part of the quote above that if
you evaluate an expression which refers to an constant external name
*during elaboration* then you can ensure the constant has been
elaborated before the evaluation of the expression, by declaring the
constant first.

> "We now assemble the design and test bench in a top-level entity and
> architecture:
>
> architecture level of top is
> begin
> assert false report "Width = " & to_string(<<constant .top.duv.width
> : natural>>);
> duv : entity work.design(rtl);
>
> "The external constant name in the concurrent assertion statement, on
> the other hand, is not evaluated until the model is executed, by which
> time the model is completely elaborated. Thus, the external constant
> name is allowed to precede the instance of the design under test in
> which the constant is declared.
>

That is if you evaluate an expression using a constant external name
*during simulation* then there is no such restriction, since elaboration
is complete by the time simulation starts.

> - END QUOTE -
>

> It says that to be sure that referenced constant is evaluated prior to
> external name reference is evaluated, "declare the constant prior to the
> part of the design that contains the external constant name".

Yes, if you want to evaluate the expression during elaboration.

But, in
> example we see the opposite: constant is declared in the instance below
> the assertion elaboration!
>

No, the example shown shows evaluation of the expression *during
simulation*.

> Then, it reassures us that this is ok and develops this idea by denying it!
>


> "VHDL has a related rule regarding elaboration of a signal referenced by
> an external signal name. If such a name (or an alias of such a name) is
> used in a port map, the signal declaration must have been previously
> elaborated. The reason is that the hierarchy of signal nets and drivers
> is built during elaboration. If a signal used in a port map is not yet
> elaborated, the elaborator would have to revisit elaboration of that
> part of the design hierarchy once the signal declaration was
> encountered. In general, allowing such use of external signal names
> would make elaboration of signal nets indefinitely complicated. The rule
> preventing such use allows elaboration to proceed in a well-defined
> order, and is not onerous in practice."
>
> That is, they say that situation is the same and object, referenced in
> external name, must be elaborated before external name.
>

The paragraph you quote refers specifically to use of a signal
referenced by an external signal name *in a port map*.

>
> alias DONE_SIG is <<signal DUT.DONE: BIT>>; -- Legal
> begin
> DUT: entity WORK.MY_DESIGN port map (s1, S2, S3);
>
> We do not want to re-elaborate the alias, once the signal declaration
> was encountered during instance elaboration. Right?
>

The alias you show doesn't refer to a signal in the port map, so I don't
think this example relates to the paragraph you quote.

regards
Alan

> After all, I could not understand if your VHDL example is correct or not.

--
Alan Fitch

[valtih1978]

>> That is, they say that situation is the same and object, referenced in
>> external name, must be elaborated before external name.
>>
>
> The paragraph you quote refers specifically to use of a signal
> referenced by an external signal name *in a port map*.

Yes, but it says that external constant evaluation during simulation "is
related" to external signals in the port map during elaboration. do they
say that external constant evaluation is treated in the same way as port
map elaboration?


Also, I could not understand why (and how) the signals, declared in the
body of subinstance, are different from port map? I do not see essential
difference between elaboration and evaluation.

The elaboration establishes the references. Evaluation uses em. Indeed,
you cannot use unestablished reference. But, in the same way, you cannot
establish it either until referenced object is elaborated. How making
exclusions for constants and port maps improves the situation?

[JimLewis]

Hi Valtih1978 (interesting name),
You don't quite have the terminology correct.

The "external name" is the hierarchical reference:
<<constant .top.duv.width : natural>>

The constant, which is in the entity duv, is:
constant WIDTH : natural := 5 ;


Hence, the required order is:

architecture level of top is
begin

-- instantiating DUV first makes objects declared in it elaborate
first
duv : entity work.design(rtl);

-- now do external name references:

assert false report "Width = " &
to_string(<<constant .top.duv.width : natural>>);

end level ;


Best,
Jim